Re: patchsets

> I know that pkgsrc maintainers simply check patches into CVS,
> but that's not really making the revision control system work
> for you.

Checking patches into version control does buy you a lot, if you do it
right. It buys you distributed changeset management that is revision
control system independent. The checked in patch sets are used to
communicate across repository boundaries. The ability of a revision
control system (just about _any_ revision control system) to act more
or less like a fairly dumb remote file system is the only feature
needed to add distributed change set management as a feature.

Here's how it comes out wrt svn:

Currently, you can note the location of an arch repository with
a command like:

        larch register-archive lord@regexps.com--2002-public \
                               ftp://ftp.regexps.com/pub/{archive-2002}

and then operate on that repository normally.

If `svn' client support was added to the program `with-ftp', then one
could register a subversion repository:

        larch register-archive lord@regexps.com--2002-public \
                               svn://..../path-within-repository

and arch would happily store and retrieve revisions from there. This
should require no changes to svn -- though it'd be nice to stabilize
the protocols involved and tune them down to something implementable
with as little code as possible, so that `with-ftp' doesn't explode.

arch revisions stored in a svn repository would not, by default,
appear to svn clients as whole trees -- they'd be mostly .tar.gz files
of change sets. This suggests the need for two additional commands:

        % svn publish ...

        % svn retrieve ...

for expanding arch revisions into full trees in the svn repository,
and computing arch revisions from full trees.

If you have two repositories to sync, one easy technique would be
mirroring. Simply `larch push-mirror' from one to the other and
`retrieve' the latest revisions, and don't worry at all about what
the larch change sets come out looking like.

Fancier syncing becomes possible too, though. After you have a working
directory from one repository (either by doing a `larch get' or a `svn
retrieve' and check-out) you can use all of larch's fancy merging
features to sync your two repositories:

        % larch star-merge me@my.laptop--work/project-foo \
                           me@work.com--devo/project-foo \
                           ./project-foo-working-dir

and, of course, change-based projects can use those commands too, both
day-to-day and in their project infrastructures. Scripts and tools
written against these commands will be portable across repository
implementations.

A similar layering makes sense for, say, CVS as well.

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 14 20:47:01 2002