Search / View

[ReD NeCKersoN]

http://sourceforge.net/projects/smokinguns/

[Tequila]

Direct link to browse Trunk on SourceForge:
http://smokinguns.svn.sourceforge.net/viewvc/smokinguns

In the case, you don't wan't to use SVN client, you still can download SVN last HEAD updates on stable branch as a Tar file, thanks to SourceForge SVN web browsing feature:
http://smokinguns.svn.sourceforge.net/v ... z?view=tar


Edited:

• Updated the link to trunk
• Added direct link to browse only the trunk

[torhu]

It great to finally have an svn server available.

But I'm wondering why the convential directory layout isn't being used. Since the repos is public, I really think it's better to use the layout that most svn users expects and are familiar with. The conventional top-level dirs have well established names and semantics. The official SVN docs recommend this practice.

This is the layout I'm talking about

/branches
/tags
/trunk

I propose this:

• Rename 'stable' to 'trunk'. That's where development will happen most, maybe all, of the time.
• Copy r49 of 'stable' to tags/1.0, or tags/1.0-win32 if the linux and Windows release are not the same. In the latter case, a copy to tags/1.0-linux should also be made.
• 'development' can either be deleted or renamed to 'branches'. I suggest deleting it, since it's possible it will remain empty forever. And empty dirs are an annoyance. The branches dir is commonly used for experimental work, or for stabilization work when the trunk is used for more bleeding edge work (or for bugfixes to old versions, etc.).

[Joe Kari]

I agree with Torhu, especially cause it's a public SVN repository.
I'm not confortable with the current tree too.

[sparcdr]

Go ahead and fix it then, I agree.

[Joe Kari]

Your attention please, I have applied those change to the SVN repository:
stable/ has been renamed to trunk/
development/ was deleted
branches/ and branches/1.0/ was created
revision 49 of former "stable/" directory has been copied to tags/release_1.0/

For instance branches/1.0/ is empty, I think it's too early to start branching right now, and suggest that people continue to commit under trunk/

[sparcdr]

Revision 25 is suitable for being marked as stable on the Windows platform, if you can figure out a consistent way of naming per-OS point releases then make a suggestion.

[torhu]

@sparcdr: Can you elaborate on you mean what by 'stable'? The purpose of tagging a revision is to keep track of exactly what code was released as 1.0 etc, for future reference. I assumed that was r49 on Windows?

@Joe Kari: Good, looks right to me now. The branches/1.0 directory is a bit pointless, though. When branching, you'd commonly just copy the code you want to start with into a new dir, there's no need to create an empty dir first. Pseudo svn command: "svn copy /tags/release_1.0 /branches/1.0.x", the dirs would have to be URLs in reality.

The online svn book contains a lot of examples of practical svn use, like the Common Branching Patterns chapter. For SG, feature and release branches might be overkill most of the time.

[sparcdr]

No, it was r48 or r49 on Linux, ask Tequila which specific build, this is what I believe he said. Windows was built on r33 mixing back in r25 client/snd* and cl_cin file because the OpenAL backport broke the build when it removed symbols. r25 can be built out of the box, while r33 is what I remember using for the release. r48 works if you merge back in the old snd* files. I've tried to reduce the amount of breakage and am making slow progress to unify the builds again with regard to what broke.

I meant r25 is stable in the sense it was the first and only to build out of the box, while it was around r33 the version (in-game) was bumped, but hardly any changes after added anything to Windows, as noted by the changelog most the fixes are for SConstruct files.

[Tequila]

Hi,

updates are okay for me.

The linux build we released is in fact r61 as I wasn't able to commit from my current job. I commited as soon as I could after I sent the binaries to sparcdr. If you check any linux dedicated server info, mine for example, it will show 20081231 as release tag in the server info panel.

So I propose we have tags/release_1.0_linux copied from r61 and tags/release_1.0_win32 copied from r25 as sparcdr suggested.

About the release, we are updating sg_version cvar at line 263 in game/g_main.c (set to 1.0 20081231 for r61) and Q3_VERSION define in game/q_shared.h at line 30 (value is "SG 1.0" here).
I think we should better have a SG_VERSION define used to set Q3_VERSION and sg_version cvar. I think we should have the SVN rev set in SG_VERSION. I would appreciate to see "SG 1.0 20081231 rev 61" for example in the lower right corner of the console.

Does it make sense for you ?

[sparcdr]

It makes sense, it'd be an easier way to expose to the public as tangible proof what build we used to satisfy license requirements to provide the corresponding source with each binary release made public. It is enough to provide a copy of the GPL license and document where to find corresponding source in another file such as a plaintext "ChangeLog" file, the installer itself, etc. as has been done already. Though what was documented is only loosely representative of what was used, given the time frame we had it was all that could be done, a rough estimate on the revision and a link to sourceforge.

[Joe Kari]

@ Torhu: branches are commonly used for stabilising a version just before releasing (and after releasing, for services release), whithout slow down people that work on new feature (trunk). Of course there are so many things to do on the code that it could sounds useless for instance. The game have too many bug, it could be just boring to merge again and again bugfix from branches/1.0/ to trunk/ that's why you are more or less right. (and that's why I left branches/1.0/ empty for instance)
But let's imagine that someone would make some huge improvement, like modifying the renderer, something that will broke compatibility to the current 1.0.x version. If someone do that, we will have to continue bugfix on branches/1.0/ while people working on the renderer will continue to work on trunk/, I'm just anticipating this.

[torhu]

My mistake about r49, just delete that tag.

The linux build we released is in fact r61 as I wasn't able to commit from my current job. I commited as soon as I could after I sent the binaries to sparcdr. If you check any linux dedicated server info, mine for example, it will show 20081231 as release tag in the server info panel.

So I propose we have tags/release_1.0_linux copied from r61 and tags/release_1.0_win32 copied from r25 as sparcdr suggested.

Ok on the linux tag.

@sparcdr: Are you sure the Windows version isn't r32, with the UI changes? I've built my non-SSE engine from r32, built with no changes IIRC. You could also reconstruct what you actually built from, and just commit it as a tag. But it might be easier to just let it go and move on to more important work.

About the release, we are updating sg_version cvar at line 263 in game/g_main.c (set to 1.0 20081231 for r61) and Q3_VERSION define in game/q_shared.h at line 30 (value is "SG 1.0" here).
I think we should better have a SG_VERSION define used to set Q3_VERSION and sg_version cvar. I think we should have the SVN rev set in SG_VERSION. I would appreciate to see "SG 1.0 20081231 rev 61" for example in the lower right corner of the console.

Does it make sense for you ?

I'm not in favor of dates or revision numbers in publicly visible version numbers. I think they should stay simple and easy to remember. The svn tags will tell us what revision was used. In test builds that info can be useful, though.

[torhu]

One thing that could be useful is just an automatically updated 'revision' cvar, containing the output of the svnversion command. I use this for Monster Browser dev builds, it's useful sometimes.

[Tequila]

Then with release 80 I just committed, I added support to SG_VERSION, SG_RELEASE and SG_SVN.

For unix build, you can set SG_VERSION & SG_RELEASE in your env and the make will define these. If not defined, they are defined in q_shared.h with the latest known good values: 1.0 and 20081231.

The SG_SVN is computed on unix system in the Makefile (making svnversion on the current folder) and a -DSG_SVN is then defined as needed.

I defined a cl_version user cvar that is transmitted to the server and it is logged if the dedicated server is at least r80:
0:43 ClientUserinfoChanged: 2 guid\5...3\n\Tequila\t\0\model\wq_male1/red\g_redteam\Les Brutes\g_blueteam\Les Truands\hc\100\w\0\l\0\tt\0\tl\0\v\1.0 20081231 r80
This could be useful to follow the client version with next releases from server side.

Torhu, as you suggested, SG_RELEASE is not reported in the lower left corner in the console, but SG_SVN is: with rev80, you will see: "SG 1.0 r80"

What do you think ?