svn package maintenance
Hello,
I've recently started to use svn for package maintenance, both in order to
enable team maintenance and because it's a great way to keep track of the
code.
Previously I used dpatch or quilt for the Debian changes. However with svn
(or any other version control system) it really doesn't make sense to use
that. The VCS is great at keeping track of changesets. Keeping patches in
svn effectively circumvents the whole point of VCS. (This is probably
obvious to anyone who has tried it, so I won't elaborate on it here.)
I'm now trying to replicate the advantages of quilt with svn. Some of these
advantages are:
*Keep track of separate changesets (sets of changes which logically belong
together).
*Individual changesets can be extracted for review or for sending upstream.
*Helps with updating the changesets for new upstream versions.
The best way to handle this in svn seems to be to use feature/integration
branches as mentioned in this talk (p. 23 ff.):
http://martin-krafft.net/phd/talks/fosdem2006-workflow.pdf
This leads to the first question: What is the recommended repository layout?
I'm currently using something like this:
branches/upstream/1.2 (upstream source v1.2)
branches/feature/fix-a-bug (branch from upstream source for a feature)
branches/feature/change-path-names
branches/feature/debian (debian/ directory is also a feature)
trunk (integration branch, for merging features)
tags/1.2-1 (Debian release)
tags/1.2-2
Of course any similar layout works equally well. The point of having a
common standard is that it would be possible to write support tools that
make this layout less cumbersome to work with. I am thinking of something
like quilt/stgit, but implemented for svn, that would understand this
repository layout, keep better track of the various branches and make it
easier to switch between them, update to new upstream versions, etc.
Does anyone else have thoughts in this direction?
Marcus
Reply to: