[arch-dev-public] The move to SVN

[Jason Chu]

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 at gmail.com> wrote:
> > On Tue, Apr 8, 2008 at 12:10 PM, Eric Belanger
> >  <belanger at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20080408/fda49b80/attachment.pgp>