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).
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.
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:
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? :)
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).
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>
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.