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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
