People needing commit access to svn

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

People needing commit access to svn

Post by chuck_starchaser »

People needing commit access to svn

I thought I was one; but while looking for my sourceforge account I discovered
that I already had commit access.
But on behalf of others needing commit access, I'm starting this thread so that
they are all together in one place.
Once we have a roughly complete list of SF names we'll contact JackS or
Hellcat and get them to make them developers.
This applies to active artists as well. I think the vegastrike and data repos
are just folders of a common repository.

Turbo needs commit, and his SF handle is turbo6.
I know Jason and nphillips need commit, but I don't know their sourceforge handles.
I'm not sure if Stingray is around anymore.
Who else?
Just reply to add yourselves.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: People needing commit access to svn

Post by safemode »

One thing to note when granting SVN access is that those people should be familiar with how to use svn.

Dont request svn access if you dont know how to properly handle conflict resolution, merging and making sure the diff's you commit only contain the changes you intend to make, and how to reverse mistakes if you do make them.
Ed Sweetman endorses this message.
nphillips
Hunter
Hunter
Posts: 85
Joined: Sun Dec 13, 2009 9:28 pm

Re: People needing commit access to svn

Post by nphillips »

My SF handle is njphillips.
stingray18
Explorer
Explorer
Posts: 9
Joined: Sun Dec 13, 2009 7:25 pm
Location: Northern Germany

Re: People needing commit access to svn

Post by stingray18 »

Hi,

yes, I'm still around ;-). Been busy reading through the sources and the forum posts. Still it's my intention to do some documentation and focus on the bug reports. Only if it helps me to understand the code. I'm familiar with using svn, we use it at work as well. But I'm perfectly happy with sending my patches to anyone with commit access.

EDIT: I don't have an SF handle (yet).
Turbo
ISO Party Member
ISO Party Member
Posts: 423
Joined: Mon Jun 11, 2007 11:54 am
Location: TX, USA
Contact:

Re: People needing commit access to svn

Post by Turbo »

I have access and have already worked out how to add, remove, and update files by updating the Masters. I don't think anyone else is working with vocal audio content but will take care to avoid conflicts.

What I need to confirm is whether changes to the data branch will update the Mac and Linux versions in addition to Win32. My linux partition died and I haven't fixed it yet. :(
Turbo

There are two speeds in combat: stopped, and as fast as you can go. Unless you run into something, going fast keeps you alive more often than stopping.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: People needing commit access to svn

Post by safemode »

I noted in the irc channel, and I just wanted to note here and hopefully it wont have to go any further than that...


Just so everyone new knows, /vegastrike and /data and /masters are not scratch repos for temporary fixes or partial commits. That's what personal branches are for. Do not commit files to either of those repos that aren't supposed to be in there for release. Also it goes without saying that you should compile your working dir and run the game prior to any commits to make sure it actually builds and runs.

This has less to do with wanting a rolling releasable svn HEAD and more to do with just not pushing off any work on other developers in the situation where someone makes a partial commit or a broken commit and then doesn't fix it in a timely manner. If it was done in a personal branch, this wouldn't effect anyone else.
Ed Sweetman endorses this message.
www2
Venturer
Venturer
Posts: 537
Joined: Sat May 14, 2005 10:51 am
Location: milkyway->the sol system->earth->Europe->The Nederland->Soud Holland->Leiden
Contact:

Re: People needing commit access to svn

Post by www2 »

Good point savemode.

edit: i heft all rady commit access to the svn.
All Your Base Are Belong To Us
Turbo
ISO Party Member
ISO Party Member
Posts: 423
Joined: Mon Jun 11, 2007 11:54 am
Location: TX, USA
Contact:

Re: People needing commit access to svn

Post by Turbo »

safemode wrote:Just so everyone new knows, /vegastrike and /data and /masters are not scratch repos for temporary fixes or partial commits.
Just to be clear, I thought that /masters was intended to store files necessary to recreate or modify content if so required. I ask because I posted ZIPPed copies of certain sounds which multiple people need to assemble multiple voice items that require inputs from multiple people. If that is not what /masters was intended for, I can remove them and use my personal FTP instead.
Turbo

There are two speeds in combat: stopped, and as fast as you can go. Unless you run into something, going fast keeps you alive more often than stopping.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: People needing commit access to svn

Post by chuck_starchaser »

Turbo wrote:
safemode wrote:Just so everyone new knows, /vegastrike and /data and /masters are not scratch repos for temporary fixes or partial commits.
Just to be clear, I thought that /masters was intended to store files necessary to recreate or modify content if so required. I ask because I posted ZIPPed copies of certain sounds which multiple people need to assemble multiple voice items that require inputs from multiple people. If that is not what /masters was intended for, I can remove them and use my personal FTP instead.
I'm no SVN expert, but I would say this is a BAD use for the /masters repo, because one of the characteristics of SVN is that it keeps enough data to reconstruct previous versions of files --by storing diffs, in the case of text files, but this is not doable with compressed files--; which means that each time you change a 10-meg audio file, compressed or not, you're permanently increasing the size of the repository by 10 megs. So, if you change a 10-meg audio file 10 times, you've added 100 megs to the repo.
Even deleting the file from the /masters repo now would not help, because SVN will keep all those versions to be able to restore any previous revision level.
SVN was designed for source code, text; not for binary data, in the first place. Binary data, such as meshes, images, sounds, and specially big files, should be considered final, as in 120% for sure Final, before committing them. The development commit model would apply to source code only, if at all.

On a slightly different topic, it seems to me the /masters repo is not being used enough for what it should be used. There are bump-maps for some units in the /data repo which lacked a normalmap ... Bump maps are an intermediate development means to producing a normalmap. The dds-compressed normalmap should be in /data, whereas the bump map and the non-dds normalmap should be in /masters.
Also a note: It appears that the standard is to have the main folder for a unit in /masters to have the uncompressed final files for the corresponding folder in /data, and any intermediate files in a sub-folder named /sources. I think this is a good system that we should continue to adhere to.
As such, the non-dds normalmap would go in /masters/units/vessels/myship,
whereas the bumpmap would go in /masters/units/vessels/myship/sources.
Not sure if the same policy has been in place for sound; just mentioning.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: People needing commit access to svn

Post by safemode »

When i setup the idea for a masters repository, it was not all that long ago. There are likely a few files that have been committed by people who were not aware or forced to adhere to the policy since then. But overall, the files in /masters were not entirely master quality type files. They were just whatever was in /data before we moved to DDS. And that data was in an inconsistent state already.

as for the first point you brought up, I agree, there should be as few commits to binary related files as possible, which is why i dont think we should see something like 12587 and 12588 ...at least not in /data. If they are source files to what will be DDS, then they should have been put in masters, otherwise the _only_ place a commit like that would have been appropriate would have been in a personal branch, as textures like that should be DDS only in /data.

The system of masters and sources and /data are all fairly new. I set it up and we outlined what was to go where but development pretty much halted soon after and things didn't have a chance to get on a roll. For a while i was entertaining the idea of moving graphics files and sound and now video out of /data and having /data only be python scripts and model type files. Then having separate repos for graphics and sound and video that can easily be packaged separately and optionally (with graphics possibly having multiple levels of quality). Perhaps in the future.

I think it would be prudent to have a sticky in here with some wiki links and any other required info on what gets committed where and how to generate the files for /data and /masters so that all that work doesn't fall on one person.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: People needing commit access to svn

Post by chuck_starchaser »

safemode wrote:I agree, there should be as few commits to binary related files as possible, which is why i dont think we should see something like 12587 and 12588 ...at least not in /data. If they are source files to what will be DDS, then they should have been put in masters, otherwise the _only_ place a commit like that would have been appropriate would have been in a personal branch, as textures like that should be DDS only in /data.
Yeah, sorry about that; I think I should have qualified "temporary" in the comment. I should have said I was unsure of the permanentness. Those textures are better left un-compressed (even the normalmap, though I did compress it; long story); and dds supports uncompressed textures, but nvcompress doesn't have a switch for "no compression". Maybe I should have tried with Gimp's DDS plug-in. I'm also unsure still about the extensions... Only bubble_norm.png has mip maps; the others are tiny textures, for solid color only, and don't warrant mips. So, I wasn't sure if I should name them bubble_diff.image, etceteras; and then bubble_norm.texture. But then again, these textures will be substitutable by local textures in a unit's folder, and those custom textures might be compressed and/or mipmapped; so perhaps they should all be named .texture regardless of compression or mips.
But given all these uncertainties, I said "heck", and purposely saved them and committed them as .png for now, --just to expedite what I consider an immediate improvement to the mining base. (Size is not an issue; these are tiny files; and for all I care I'd leave them as they are.) But perhaps I should have put them in the MiningBase folder, or have asked first what's the right format and naming.

EDIT:
The other reason I said the commit was "temporary anyways" was that I was planneing a new, special shader and technique for glass, and thought it might need a different texture set. Now that new shader and technique are almost done (debugging stage), and as it turns out they use the same texture set.

Question: are there any functional consequences to naming a texture .image or .texture? Or is it simply a matter of convention?

Also, is there a functional difference in whether an un-compressed texture is saved in .png or .dds format?

Suggestion:
It should perhaps be clarified that small textures (up to, say, 256x256), in shared space (under the /textures folder) should preferably be un-compressed, as the benefit to color precision is substantial (specially for normalmaps!); and given that the price to pay in terms of video memory is small, considering their size, and that they may be shared by multiple units at runtime. ((And by "un-compressed" I mean avoiding DXT compression; they could still be .png compressed if it reduces size substantially, for all I care. And the issue of mipmaps is orthogonal to compression, but not to format... With DDS format one can have an un-compressed texture with mipmaps, which I don't think .png supports; but on the other hand, mips can be produced on the fly, if absent, and I think the engine does this anyways; right?))
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: People needing commit access to svn

Post by safemode »

filenames dont matter when it comes to images to the game. We dont care about extensions, we use filemagic via internal headers.

But, as a rule,
basically, .texture is a file that is used in the 3d aspect of the game. It has mipmaps or is an uncompressed file that will get mipmaps generated for it by the game...which is what happens when a 3d targeted texture without mipmaps is loaded.

.image is a 2d targeted image ....most commonly loaded as base images or such things. Perhaps cockpit images.

In no situation should filetype extensions be used, as they would then require editing models and other places that specifically refer to them whenever the internal filetype changed, either that or we are left with the situation we have had until recently where filename extensions were misleading.

So, if it is visible in an external view while flying around in space, it should probably be .texture. Otherwise .image or .sprite, etc.

As for uncompressed dds files, as another rule, i would definitely consider those files valid, but only if they are small. Ie, maybe only less than 128x128. The gimp-dds plugin may allow for uncompressed, but it is video card specific, as it uses hardware compression. nvcompress does not. Leaving it as png is best, but named as .texture. so long as it's sufficiently small. .png's dont get compressed to dds in realtime, like non-png files do, but we will generate mipmaps on the fly using opengl's algos. If that's insufficient, perhaps we should focus on figuring out how to better create mipmaps on the fly.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: People needing commit access to svn

Post by chuck_starchaser »

Okeydoc, thanks. I'll svn-rename them with the next commit.

OpenGL's algos are fine for mipmaps on the go. There are many fancy scaling algorithms out there; but image downscalings by a factor of exactly two are a special case: they are the best when using simple averaging.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: People needing commit access to svn

Post by pheonixstorm »

I may need it as well. If my Priv PU editors are useable for VS then I would need svn access to add then to the tools dir as well as any possible fixes I have to make in the main src dir for creating a win32 compile. My SF name is same as my forum name.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Re: People needing commit access to svn

Post by ace123 »

What's your sf.net username?
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: People needing commit access to svn

Post by pheonixstorm »

pheonixstorm, same as my forum name.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
Post Reply