Lars:
I'm a happy user of subversion, but I think that changesets
would be nice, so I have been looking into them a little.
I have the feeling that subversion has most of the mechanisms
necessary for changesets in place, but lacks the 'front &
middle' end.
So I am going to download the subversion source and have a
look, but in general is everyone positive to changesets ?
What I was thinking was basicly to figure out a good way to
enable working with changesets ( local repositories ) and
repositories on servers. I thought that basicly you needed to
be able to have some local repositories to work on, which
should be very easy with the file: url.
I am looking at what arch is doing but I have to get used to
the code first.
So this is just a small wuestion about if everyone thinks this
would be a good idea ? ( changesets ? ).
I've done some thinking about and coding towards adding changeset
functionality in SVN.
It sounds as if your primary interest is in using changesets as a unit
of exchange between local and remote repositories. If so, I encourage
you to think about defining changeset formats and meaning
independently of any one revision control system. For example, I
strongly suspect that some Linux kernel contributors who don't use
BitKeeper would love the ability to use svn locally and exchange
changesets with BitKeeper users and others. I think it likely that
there are GCC contributors who currently keep private CVS archives
that would love to switch to svn while the project still uses CVS,
exchanging changesets among themselves and to submit patches to the
GCC maintainers. If you have system-independent changsets, that makes
it easier for 3rd parties to write tools that manipulate those
changesets.
Defining changesets well is actually moderately hard. I've watched
about four people (including myself) sit down to try to define
changesets and every single one of us started out in exactly the same
"obvious" way and every single one of us therefore got it (initially)
_wrong_. Whole-tree, rename-happy changesets are a touch
non-intuitive: it's a "measure twice, cut once" kind of situation.
A lot of work on defining and implementing system-neutral changesets
has already been done in the arch world. Our basic changset
manipulation tools are, at this stage, about 50% factored out of arch
itself. The part that has already been factored out was coded with
svn in mind -- it contains some _tentative_ "hooks" where knowledge
about the format of svn working directories (and other systems) can be
plugged in; I added those in anticipation of one day sitting down with
svn developers to work on a revctl-neutral standard for changeset
format and meaning (and assumed that the exact nature of those hooks
would have to change -- they are mostly there just to convey the rough
idea (to people reading the code) of how the generalization fits in to
the tools).
I think you're on a slippery slope, by the way. You might start out
with just a very simple use-case in mind and build support for that,
but I think it's pretty easy to go from there to expanding their
usefulness and implications for svn users quite far.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 25 20:40:03 2003