$12256 / $11500
Hi there,
I just checked out the whole svn repo holding flare including branches and tags, both are empty.
Why is that? How are the point releases (e.g. the 0.12-foo.zip) get created and how can I see which svn commit number relates to these?
Thanks for the great peace of soft by the way, I like it a lot.
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
I vaguely understand the concepts of branches and tags, but so far I'm not using them in Flare. So far they haven't been strictly necessary so I skipped it.
One (inconvenient) way to see which commit number goes with which point release is to look at the google code update history. https://code.google.com/p/flare-engine/source/list I'm the only committer, so it should be in order.
Hi Clint,
the ideas behind branches and tags are the follwoing:
Create a branch if you want to add/change a major feature that takes a while and renders the main code in trunk unusable / uncompilable. Doing this, makes it possible to patch the code in trunk if there should be any bugs.
If the effort in the branch does not succeed, simply delete it, trunk was not touched then.
If it succeeds, it gets merged to trunk again.
If you reached a milestone, you usually create a tag from trunk like this:
svn copy http://svn.example.com/repos/flare/trunk \
http://svn.example.com/repos/flare/tags/release-0.13 \
-m "Tagging 0.13 release of flare."
This is done to have a good archive of the code. It makes it _much_ easier for people to package your project for Linux distributions, create installers from it etc.
I play with the idea to create a debian package for flare. Are you convinced that is a good idea to create tags now? :)
Do you have any other thoughts regarding my idea?
All the best.
hennr, I'll start tagging with v0.13. Thanks for your pointers!
Nice, that's good news.
No input regarding the packaging idea?
Packaging for any distro is great. I know someone is doing it for Arch Linux already. Let me know if I can help in any way, though I don't know much about packaging for distros/repos.
I do plan on looking into the openSuse Build Service when the game is a little further along.
OK, cool.
I had a look at the OpenSuse build service as well, it's nice for the beginning but it's clearly better to have packages "upstream" so people can install it directly and don't have to add another repo.
in my office we also branch off when a major version is realeased and if there are any bug fixes we increment that branchs version with the fixs. and main work continues in trunk/ feature branches.
so for example you release 1.0 you put a copy in tag of course, then you put another copy in branch. and you start working on 1.1 in the trunk branching off new features as needed if ppl find bugs you make the changes in branch and release 1.0.1 and in the mean time you have version 1.1 being developed in main trunk. when releasebranch is publicly released i merge back into trunk but sometimes som bug fixs are not required in trunk since the function is depriciated in new release. so bug does not exist or else we merge and new version includes bug fixs.
so this is a bit diffrent then what hennr explained but at the end its up to you how to keep the tree going
Yeah, I don't care how flare gets developed internally.
The most important thing for packaging is that every release, including a bugfix release of course, gets tagged so I can easily check that out and build a package including all fixes.
<ads>
An interesting fact is that svn repos become bigger and bigger with every tag. git on the other hand only saves diffs and links to trunk to keep the repo _much_ smaller. It's faster to checkout and work with.
I checked out flare including the tags and _all_ revisions ever made into a git repo (using git-svn). The git repo is 575 MB in size while the svn repo is already at 826MB. Note that svn stores the revisions on the server while you have those completely offline with git.
</ads>
@hennr
In your ads, I think you made a little error: the SVN repos don't become a lot bigger when you make branches (or tags, as they are both a simple copy of a directory). SVN only keep the diffs, as git. Only your working copy is growing, as with git again I think. The SVN repo of Flare is only on GoogleCode.
I agree on the faster checkout for git (as it clone the repo, which is smaller to download) and the offline work possibility.
More important could be the easier possibility with git to commit locally little patches on several subjects and push them separately to Clint, which is better than a big patch that change a lot of areas.
@Bonbadil
GIT is not a CVS variation like SVN. As far as I know GIT doesn't copy files on branch. It just maintains a new node and a link in a graph. Can't find any qualified info on the web right now - that may be the reason for doubt. It was one of the main points in Linus talk at google tech talk. For first hand implementors info from Linus himself go to google videos and search for git.
I don't like that "mine is better than yours"-talk but this site seems to lists some facts despite it's name: whygitisbetterthanx.com
But I think the Topic was tagging and branching in Flare?
About branching for versions and patches as the other Anonymous pointed out: It is a good idea for companies and products where you need to maintain individual versions for old *paying* customers who rely on version x - but it's probably unneccessary overhead for common game projects. Third party forks are used as the weapon of choice to maintain a certain gameplay in the open source world. And branches seem to be good for experimenting with features on your own (with SVN everybody can see your trials of course if you want to secure them).
To clarify the svn branch / tag post I made.
I talked to a subversion developer and he hold me that svn will make a cheap copy only. Means that it will link / diff but will not make a full copy of all files.
Sorry for posting that.
Nevertheless is the git repo smaller while holding more information (all revisions).