News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Tags in SVN and (inofficial) Debian packages

Started by ansgar, July 21, 2009, 10:13:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ansgar

Hi,

it would be nice if the pak128.Britain releases could be tagged in Sourceforge's SVN.  That makes it much easier to get a specific release.

I also created preliminary Debian packages that are available from http://www.43-1.org/~ansgar/simutrans-pak128.Britain/.  They may [1] work with the Simutrans packages from Debian/Ubuntu.

Regards,
Ansgar

[1] May means at least the game did start, but I did not test much.

jamespetts

Ansgar,

thank you very much for your help. How would we go about tagging as you suggest? Would this work for my Experimental version of Pak128.Britain, which is currently on Github, not Sourceforge?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ansgar

Hi,

creating tags is described in the SVN documentation [1].  The documentation assumes the recommended repository layout [2] is used, which neither Simutrans itself nor pak128.Britain use right now (it should be possible to switch to the recommended layout using svn move, but users might have to use "svn switch" to change to the new layout).

In Git, it is also possible to tag commits with the "git tag [-a] <name>" command [3].  You have to push the tag to the repository on Github after this (git push origin <name>).  The schema "v[version]" seems to be in common use for tag names in Git.

Regards,
Ansgar

[1] http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html
[2] http://svnbook.red-bean.com/en/1.5/svn.branchmerge.maint.html#svn.branchmerge.maint.layout
[3] Passing "-a" will create an annotated tag, this means you can store a tag message (similar to commit messages).

jamespetts

Ansgar,

thank you for your swift reply. Can the tagging be done in the Git GUI that I always use? What exactly is the tagging, in any event? What tags should be used?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

But then the repository will need large amounts of my harddisk, which is limited.

ansgar

#5
Hi,

"tagging" is simply giving a revision a name, so that you can refer to release 1.02 (or /pak128.Britain/tags/release-1.02 in full) instead of SVN rev 16543.  It makes it easier to find them later.  Usually you would (at least) tag every release.

If you do not check out the full tree, but only the trunk/ directory, the working tree will not take more space [1].  If you want to support full-tree checkouts, it's also possible to use a layout like


   /trunk/<module>
   /tags/<module>/<tag>
   (and /branches/<module>/<branch> if there are branches)


and then only checkout the trunk/ directory (the contents of /trunk/ would be the contents of / now).  Switching the layout this way would of course affect everybody who has a working tree, not only those that have a working tree for /pak128.Britain.

Ansgar

[1] It will not require much space on the server in any case.

Ashley

This is a good idea, I use a similar system for my repository, with a layout of:

/repos/<project1>/trunk/
/repos/<project1>/branches/
/repos/<project1>/tags/
/repos/<project2>/trunk/
/repos/<project2>/branches/
/repos/<project2>/tags/

And then tag releases by copying their revision number over to the /tags/ directory in suitably named folders. Since I keep all the build info version managed too it's a simple matter to build a particular revision to check out /repos/<projectX>/tags/release_0.2 (for example) and then just run the build script.

It's better to go with a structure like:

/repos/trunk/<project1>/
/repos/trunk/<project2>/
/repos/tags/<project1>/
/repos/tags/<project2>/
/repos/branches/<project1>/
/repos/branches/<project2>/

In situations where the projects are very intimately linked and you'd likely be checking out the whole of /trunk/ at once. In this case you're kind of just having one project with multiple subfolders of course. Subversion doesn't care in any case :)

And to answer Prissi, yes, if you have a bunch of /tags/ releases and you check out the entire repository it'll use quite a bit of disk space in your working copy (very little is used on the server of course, since the tagged release is identical to the version it was copied from). But it'd be pointless to check out all of /tags/ for your working copy since this is meant to be an entirely static copy of a particular revision anyway.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

prissi

Well but below pak64 there is pak.Britain. So with our svn structure this is not really feasable, some movement would be required. But even more, since most of it are binary data and old paksets could be still compiled from the new files (just an old makeobj is needed, which is not contained anyway) I do not find this structure neccessary. Apart from having identical images many times really eats harddisk fast (especially on 4GB netbooks, which will be my main computer for the next weeks).

I fail to see the difference to a logfile. I coudl still do an svn log|grep release and then an svn up -r xyz. THis will also be static data.

ansgar

There is no pak.Britain in SourceForge's SVN (at least I cannot see one).  You can also just start with tagging (sub-)projects where this is already possible, like pak128.Britain.

If you only checkout the /trunk/ part, it will *not* require any disk space on your computer.  There is no need to checkout everything. Tags also require almost no disk space on the server as well (Subversion only nees to store the information that there is a copy, it will not store the actual files twice).

Regarding the last point, it does not work if there is no comment in the log [1].  If there is a history file (as for Simutrans itself), it even requires a working tree to just look which revision belongs to which release. In contrast, you can get a list of all tags via svn ls (or the web interface) and get a specific release easily [2]. Also there is the point that you'll find tags almost everywhere else.

Regards,
Ansgar

[1] as for pak64, I guessed which revision actually should be the release and be used for the Debian packages.
[2] And this can be done automatically by a program that notices when a new release appears. Yes, my true goal is to make my life easier ;)

prissi

As said, for pak64 always the newest release should be used. If the makeobj is from an older version, the additional entries will be ignored. The only exception is the menuconf.tab, which is revision dependent, unfourtunately.