On Tue, Apr 08, 2008 at 02:14:57PM -0500, Dan McGee wrote:
On Tue, Apr 8, 2008 at 12:44 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, Apr 8, 2008 at 12:10 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
Things I would like to know how to do with the new SVN repo: - how to checkout the whole repo and how to update it afterwards
I just want to say that this is not really recommended. The size on disk is huge (SVN keeps a copy of the HEAD revision in the .svn/ directory, so the overall size of the checkout is double that of the actual files). Feel free to do it, but I know I won't be doing it.
Not to mention that fact that one individual package has copies in the repos/ dir too. A package in extra and testing for both architectures has 5 copies of the tracked files (and 5 more for the svn HEAD revisions). So that's a totaly of 10 PKGBUILDs and other files for one package. We have 2500ish last I checked.
Damn, this kind of sucks. I've always liked the fact that I can get all of the content of the Arch repos locally without it being a pain in the ass- it is really nice to be able to search through every PKGBUILD for instance for broken licenses, etc. Does SVN have some sort of exclusion feature that can be used when checking out to only get folders that look like */trunk/* for instance?
I'm not sure that svn can, but it's possible svk could. Either way, actual merges between trunk and repos/ would *have* to be done by svnmerge. Abs will still be laid out the same way and also be a really good way to grep through all the PKGBUILDs for random data.
Another quick question- say we have libfoo-3.0.0 in testing, which needs to sit there for rebuilds, but a critical security fix in libfoo-2.5.7 comes out (and we currently have 2.5.6 in extra). Can our dbscripts and devtools handle this case where I actually DO want to edit the non-trunk PKGBUILD?
This was one of the main design decisions. Multiple versions can be tracked at any time (I like to call the feature "actual branches"). The archrelease script really just uses svnmerge to merge changes from trunk to repos/. svnmerge is the key that makes this all work. That's why I'm stressing that we have to use it so much. svnmerge is able to look at two paths and ask the question, "which changes haven't been merged yet?" If we merge changes from trunk to repos/ without using svnmerge, it won't know about them and it'll try to merge them again. If there is a case where svnmerge is confused because something was done in a different way, it is possible to fix. I just don't want people making those sorts of changes and making me clean up the mess ;) Jason