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

[Dan McGee]

OK, This is part one of two on the killing CVS topic for me tonight.
In this email, I'll respond to Jason's SVN suggestion. In the next
email, I'll present my GIT suggestion. Let me start this off (and I
will finish my other email this way as well) that to date, Jason's
suggestion below is THE BEST solution I have seen yet. I'll let you be
the judge on my GIT solution.


On 10/17/07, Jason Chu <jason at archlinux.org> wrote:
> 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).
I've noticed this at work as well- I do think an ssh-based checkout
would go faster than an HTTP one?

> 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).
This does seem like a plus. However, some other developers did bring
up the point that in order to get all deps right you will probably
need the whole tree anyway. I think the takeaway point here is it
shouldn't be a pain in the ass to get everything.

> 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)
Easy = good. Always. That is what I am afraid of if we pick any VCS
besides CVS/SVN- the command set can be overwhelming and not familiar
to anyone that has only used a centralized VCS.

> b) To put a package in multiple repos, just archrelease the trunk (or svn
>    copy or svnmerge from a different repo).
CVS tags were a dirty but effective solution for doing what we needed
to do with multiple repos, but it just didn't cut it when we had to
manually move files around from current/core to extra and stuff. This
is clean and simple.

> 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.
What would the advantage/disadvantage be of editing this file instead
of the trunk file? If it was a testing branch file, I could see that.
Actually nevermind, this makes sense- keep the edits local to where
they belong, but make them at the highest point possible.

> d) Different architectures are dealt with just like repos, it's the db
>    scripts that will treat these directories differently.
As long as the strategy could logically expand architectures, I like it.

> e) Commits to trunk don't automatically go anywhere, people can make
>    whatever changes they want without first rolling back other people's changes.
This is smart and similar to the way HEAD and CURRENT can differ in
our current repos.

> 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.
This could hurt when it comes to huge rebuilds.

> 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).

-Dan