[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Archiving merge metadata, class project...

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-11-20 18:48:26 CET

On Thu, 2003-11-20 at 00:02, Jennifer Bevan wrote:

> So, I'd like to ask if anyone familiar with the
> issues would like to spend maybe 1-2 hours IRCing with me
> over the next two weeks, to make sure that I produce something
> you all would like to see.

Hi Jennifer,

I have two comments...

First, it sounds to me like you're talking about something a lot more
sophisticated than what most of us around here have been calling
"merge-tracking". The main problem we plan on solving is avoiding the
"repeated merge" problem, as discussed in the svn book. Our hope is
that we could use metadata (properties) to store information about
exactly which changesets have/haven't been merged into certain
branches. The ultimate goal was to alleviate users from having to
manually figure out the starting points of branches, or the exact set of
changesets to merge: the system would just merge whatever changesets
are "new", since the last time a merge happened.

But it sounds like you're talking about a system with much higher
granularity; you actually want to store information about the way
textual conflicts are resolved within files. Do other SCM systems do
that? (Big ones, like Clearcase?) Anyway, I might recommend starting
with the 'smaller' problem of simply tracking merged changesets, and
then if time permits, looking at the more complex problem of tracking
conflict resolution within files. (The simpler problem is the one I've
heard users repeatedly clamor for, while I've never heard anyone wish
for conflict tracking.)

Second, you've caught the developer community at a bad time. We're in
the middle of a feature-freeze. Most of the developers focusing very
hard on stabilizing svn into a Beta release, with a 1.0 soon to follow.
This means many of us don't have time or energy to design large new
features; that's the reason merge-tracking has been tabled as one of
those big "post-1.0" discussions (along with locking, and other things.)

My recommendation is that you do what a bunch of us did when designing a
locking system: grab a bunch of interested svn people, have some
private email or IRC discussions, and present the project with a design
document. We can check it into the notes/ directory, right next to our
locking-design doc. After 1.0 is out the door, the community will break
out the design documents as starting points for discussion.

By the way: Chia-Liang Kao (clkao@clkao.org) has spun off a new SCM
system from Subversion called 'svk'... he's already written a
merge-tracking system, so I bet he'd love to chat with you.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 20 18:50:07 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.