c) Could you explain how the usage would work with the svnmerge tool. Personally, it's a little confusing with the repos/ dir, even though I had a small part in this original idea 8)
svnmerge came out recently with subversion. The basic premise is that subversion is dumb about merges. It doesn't store any meta data when you merge a set of changes from one branch (directory) to another. This means that if you try to merge the same thing twice, you'll get a merge conflict (like applying a patch twice). svnmerge records which revisions have been merged into a branch. Now, the repos/ dir is what we use to keep track of the actual package repositories. Possible subdirectories of repos/ are core, core-64, extra, extra-64, testing, testing-64, unstable, and unstable-64. Any files in these directories are "tagged" as the versions in the package repository. Other directories will be allowed when we want to start making custom repos on the fly (kernel26, xorg, etc). If you think of the trunk/ directory as the HEAD CVS version (where most changes to a package are recorded), the repos/ subdirectories are our CURRENT/TESTING cvs tags. svnmerge helps us get the changes from trunk/ into our particular repo branch. The reason we use svnmerge instead of just svn copy is because svn copy won't overwrite directories ("svn cp trunk repos/core" if repos/core exists will create repos/core/core) and, more importantly, because we can make specific changes in the repos that aren't tracked in trunk. An example of such a situation came up with python and a security fix (I've modified the original situation slightly to explain things better). Python was updated in testing and a bug was found in the packaged version in extra. The bug had been fixed in the testing version, but people who weren't using testing didn't have access to it. In CVS, I would have to get a copy of the old PKGBUILD, roll back all the testing changes, apply the security fix patches, commit, tag, and apply the testing changes again for each architecture. In this new SVN scheme, I just have to edit the PKGBUILD in repos/extra and repos/extra-64. I guess I never went through the actual usage. Basic usage to expand on your example: cd ~/mypackages archco gtkpod cd gtkpod/trunk # Make changes svn commit -m 'my changes' archrelease extra To explain the python example up above: cd ~/mypackages archco gtkpod cd gtkpod/repos/extra # Make extra-specific changes svn commit -m 'my changes' cd ../../trunk # Make trunk-specific changes svn commit -m 'awesome new version with changes going to testing' archrelease testing # Time passes (signoffs, etc) archrelease extra There is one thing we'd want to check svnmerge for. In the second example, svnmerge will probably try to merge the specific extra changes with the overarching testing changes. If we applied a patch that isn't needed in the testing version, it'd be nice not to merge in this case. The problem is that it's a 3 or 4 step process with svn and one of those steps actually "untags" the package in the repo. We'd have to modify archrelease to handle this sort of case.
Other:
This implementation grew on me as archco did. I don't think it'd be as easy with an other SCM. But I still am a little put off by svn - after having used fancier SCMs out there, I don't really like the tamer ones anymore. git has some GREAT tools, but I don't think we'd need half of them.
I really do think in this case we're using the strengths that svn has that other version control systems don't. The biggest two are partial checkouts and branches being directories (which means very very simple branch management). The funny part is that these are the exact features that don't help when working on complex interrelated source code. That's why it's more difficult to apply some other version control to package management.
I'd still love to see a git or even mercurial implementation (bonus points: mercurial works on Win32 better, so we could ease into a 'cygwin' arch, which is something I wanted to try out for a while, hah). When I have time and finish up some things I wanted to finish, I will see about a git implementation. I believe Dan already has something, so he may beat me.
Doesn't git work on win32 as well? Jason