[arch-dev-public] Killing CVS [was: Status Report 2007-10-15]

Jason Chu jason at archlinux.org
Wed Oct 17 15:28:45 EDT 2007

On Tue, Oct 16, 2007 at 02:30:18PM -0500, Aaron Griffin wrote:
> On 10/16/07, Jason Chu <jason at 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:


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:


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20071017/00cd9ec7/attachment.pgp>

More information about the arch-dev-public mailing list