> So, personally, I think it makes sense to keep that "whole
> project" merge history automatically. It _can_ be done
> without deep changes to svn itself -- i.e., it can be
> regarded as a layer over svn. Among the payoffs of that
> approach is that it can buy a useful form of distributed
> repositories for not-quite-free-but-cheap (i.e., by
> recording that history in a repository-neutral way).
Hmmm, that's pretty tantalizing :-).
Can you describe this record-keeping layer in more detail
(i.e., enough detail to implement)?
Well, you can find a surprisingly useful prototype (not tied to svn in
any way) at "regexps.srparish.net/www" :-) I can try to give you
some quick hints to orient you around that code.
I think that the tentative idea I have in mind might make the most
sense from the svn perspective if initially regarded as a set of
(semi-automated) conventions for how you lay out a repository.
That is: at it's core, svn is completely free-form about repository
layout and has it's particular concepts of file and directory history.
But then on top of that, one tends to build conventions -- such as how
to layout branches, and how to use tags, and how to organize multiple
projects in a single repository. (At least that's my understanding.)
Ok, well, looking at that Other Project mentioned above: you can
squint at it and subtract out the details of the particular
implementation -- and regard it as a big collection of conventions and
standards-in-waiting. Standards about, for example, how to name
development lines and revisions in a repository-independent way;
standards for how to record (in the source tree) the history of merges
between those repository-independent development lines; etc.
Putting these together, I see the (not fully developed) idea of
mapping the conventions from the Other Project into the layout of a
svn repository. For example, where the Other Project might store a
revision in its low-tech archives by squirreling away a .tgz tar file
of the changeset, in svn, the analogous operation would consist
(approximately) of forming a suitably named tag (directory copy). In
BK parlance (I'm informed), this mechanism would be comparable to the
checkin/commit paradigm ("BK checkin" being _roughly_ a svn commit --
though svn commits are fancier; "BK commit" being _roughly_ -- form
that tag that groups a set of checkins into a globally named
changeset, suitable for use in review, distribution, and fancy
merging).
"Distribution for free" falls out of that not by trying to fully
distribute complete svn repositories -- but by distributing the
high-level development lines that are defined by the various naming
conventions. That is -- you get distribution right where you need it:
at the project management level rather than the svn schema level.
The "record-keeping layer" you're asking about has a few elements.
There's a global namespace for development lines; there's an
inventory mechanism for identifying files within revisions of those
development lines; there's a logging mechanism for keeping a record
of which changesets have been applied to what trees (in terms of the
global namespace). As far as core-svn is concerned -- all that stuff
is just additional source files in project trees.
A crude approximation might be: when I merge trunk@X into branch I add
a note to the file branch/merges. And then later, when I want to do a
history sensative merge or compute an interesting changeset, that file
branch/merges is handy. In the Other Project -- that "branch/merges"
file is replaced by a tree of RFC822ish log messages whose header
fields automatically accumulate the merging data (along with a bunch
of other stuff).
(Another feature this can get you "for free" is a mechanism comparable
to CVS modules -- but a bit more featureful. The global namespace
gives you handy names for separate projects within a repository. You
can define "modules" (we call them "configurations") in terms of that
namespace, and keep versioned records of those modules and how they
relate to releases.)
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 02:54:02 2003