On Tue, Oct 16, 2007 at 02:30:18PM -0500, Aaron Griffin wrote:
On 10/16/07, Jason Chu <jason@archlinux.org> wrote:
If we run into problems later with a solution, I know I'll feel like saying "I told you so".
I didn't want this to turn to opinions and fanboy-ism, but it appears to have happened in record time.
I need to repeat this point. About 2 months ago I converted extra and current to git repos. Full history and tags were kept and very little changed. It was done in about 10 minutes. I committed to git and converted back to CVS is about the same time.
So, let me make this abundantly clear:
We can't fuck this up. <<<
There is no way anything gets lost besides time. We're already soaking time by going off on these little tangents.
I don't care about what Aaron says here. Whether I disagree or not really doesn't matter. The point he's trying to get to is let's try something (without necessarily putting it into place right away) and talk about that instead of just talking about the ideas. So, I'm doing my part. A while ago there was talk of a different svn layout that we could use to help us track repos apart from the version control repo. For those of you that remember, good for you! To quote an email from Paul, the problems this method is trying to solve are thus:
a) Moving packages from one repo to another is hard. b) Placing packages in multiple repos is hard. c) Continued separate-track development on a package while in testing is hard. d) Tracking multiple binary repos for different architectures is hard. e) Maintenance of a package by more than one person is hard.
It addresses all of these issues fairly well, if I do say so myself. I tried writing some scripts for it and using a new tool (svnmerge) to possibly help keep versions in sync. I can recreate the svn repo using the newest changes in about an hour. I created the current repo based on changes as of last night. I will now share what I have done. First the svn repo: http://projects.xennet.org/svnarch/ You can svn co the whole repo by itself, but (last time I tried) it takes about 2 hours to do (it isn't network traffic either... I think it's just a limitation of svn). A better suggestion (and the whole point of this layout) is to only check out the packages you need (and possibly even remove the working copies when you're done). I've written a couple of scripts (archco, archrelease, and archrm) to help with this flow. The basic flow of this method goes like this: 1) archco package you want to update 2) edit the files in trunk and commit as if you were a developer doing whatever you wanted to do to source code 3) once all changes are commited, run archrelease <repo> from the trunk directory -- this will merge all unmerged changes from trunk into that repo or create the repo if it doesn't currently exist 4) archrm the directory While a checkout of the entire repo takes 2 hours, checking out a package takes about 5 seconds. Now, how does this address Paul's points: a) Moving packages from one repo to another is a simple svn copy (or svnmerge, depending on the situation) b) To put a package in multiple repos, just archrelease the trunk (or svn copy or svnmerge from a different repo). c) Files in <pkgname>/repos/* can be edited and commited to as if they were in trunk. This should work even when wanting to merge other changes from trunk into that repo later. d) Different architectures are dealt with just like repos, it's the db scripts that will treat these directories differently. e) Commits to trunk don't automatically go anywhere, people can make whatever changes they want without first rolling back other people's changes. The major flaw that I can find with this layout is that bulk editing becomes more difficult. Because we don't a) abuse CVS tags and b) check out the whole repository, mass changes are difficult to apply to packages. Eventually, I'm confident that the tools we write can make up for this. archco, archrelease, and archrm can be seen here: http://projects.xennet.org/svnarch-tools/ Notice that these scripts are really simple. archrelease would need to be expanded later (as would the FIXME in archrm). Feel free to try things out. If you want write access, just send me an email. I've been applying random commits that I see an arch-commits and everything is really easy. Jason