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

[Jason Chu]

> c) Could you explain how the usage would work with the svnmerge tool.
> Personally, it's a little confusing with the repos/ dir, even though I
> had a small part in this original idea 8)

svnmerge came out recently with subversion.  The basic premise is that
subversion is dumb about merges.  It doesn't store any meta data when you
merge a set of changes from one branch (directory) to another.  This
means that if you try to merge the same thing twice, you'll get a merge
conflict (like applying a patch twice).

svnmerge records which revisions have been merged into a branch.

Now, the repos/ dir is what we use to keep track of the actual package
repositories.  Possible subdirectories of repos/ are core, core-64, extra,
extra-64, testing, testing-64, unstable, and unstable-64.  Any files in
these directories are "tagged" as the versions in the package repository.
Other directories will be allowed when we want to start making custom repos
on the fly (kernel26, xorg, etc).

If you think of the trunk/ directory as the HEAD CVS version (where most
changes to a package are recorded), the repos/ subdirectories are our
CURRENT/TESTING cvs tags.

svnmerge helps us get the changes from trunk/ into our particular repo
branch.  The reason we use svnmerge instead of just svn copy is because svn
copy won't overwrite directories ("svn cp trunk repos/core" if repos/core
exists will create repos/core/core) and, more importantly, because we can
make specific changes in the repos that aren't tracked in trunk.

An example of such a situation came up with python and a security fix (I've
modified the original situation slightly to explain things better).
Python was updated in testing and a bug was found in the packaged version
in extra.  The bug had been fixed in the testing version, but people who
weren't using testing didn't have access to it.

In CVS, I would have to get a copy of the old PKGBUILD, roll back all the
testing changes, apply the security fix patches, commit, tag, and apply the
testing changes again for each architecture.  In this new SVN scheme, I
just have to edit the PKGBUILD in repos/extra and repos/extra-64.

I guess I never went through the actual usage.  Basic usage to expand on
your example:

    cd ~/mypackages
    archco gtkpod
    cd gtkpod/trunk
    # Make changes
    svn commit -m 'my changes'
    archrelease extra

To explain the python example up above:

    cd ~/mypackages
    archco gtkpod
    cd gtkpod/repos/extra
    # Make extra-specific changes
    svn commit -m 'my changes'
    cd ../../trunk
    # Make trunk-specific changes
    svn commit -m 'awesome new version with changes going to testing'
    archrelease testing
    # Time passes (signoffs, etc)
    archrelease extra

There is one thing we'd want to check svnmerge for.  In the second example,
svnmerge will probably try to merge the specific extra changes with the
overarching testing changes.  If we applied a patch that isn't needed in
the testing version, it'd be nice not to merge in this case.  The problem
is that it's a 3 or 4 step process with svn and one of those steps actually
"untags" the package in the repo.  We'd have to modify archrelease to
handle this sort of case.

> Other:
> 
> This implementation grew on me as archco did. I don't think it'd be as
> easy with an other SCM. But I still am a little put off by svn - after
> having used fancier SCMs out there, I don't really like the tamer ones
> anymore. git has some GREAT tools, but I don't think we'd need half of
> them.

I really do think in this case we're using the strengths that svn has that
other version control systems don't.  The biggest two are partial checkouts
and branches being directories (which means very very simple branch
management).

The funny part is that these are the exact features that don't help when
working on complex interrelated source code.  That's why it's more
difficult to apply some other version control to package management.

> I'd still love to see a git or even mercurial implementation (bonus
> points: mercurial works on Win32 better, so we could ease into a
> 'cygwin' arch, which is something I wanted to try out for a while,
> hah).
> When I have time and finish up some things I wanted to finish, I will
> see about a git implementation.
> I believe Dan already has something, so he may beat me.

Doesn't git work on win32 as well?

Jason
-------------- 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/20071020/a65fd3aa/attachment.pgp>