Archiving merge metadata, class project...

[Jennifer Bevan <je...@bounce.alouysius.net>]

Hi,
Ben suggested that I try here for an in-depth response to
my questions.

I am a graduate student at UCSC, and have been using subversion
since around revision 1100.  As a class project, I would like
to do an initial pathfinding/feasibility study on adding
archiving of merge attributes (to Properties, as Ben mentioned 
is planned) and possibly even previous conflict resolution data.
I'd like this to be something useful for the Subversion designers
as well.  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.  Any 30-second pointers to where I 
should start examining the code will also be helpful, of course!

One main goal of this work is to maintain the overall design
goals built into Subversion; hence, the archiving of data
previously only available through controlled workspaces
(like conflict resolution activities, merge choices, etc.)
may have to be approached cautiously.  Do we want users to
have to peform more steps for each merge done?  Should 
subversion only archive the data it can get without any more
user effort?  I'll also need to know these sorts of constraints.

So, if anyone is interested in helping out with this project,
please let me know.  My hours are fairly flexible and I can
probably work around your schedules, when live communication
is necessary.  

Thanks,
Jennifer Bevan


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Archiving merge metadata, class project...

[Jack Repenning <jr...@collab.net>]

On Nov 20, 2003, at 9:48 AM, Ben Collins-Sussman wrote:

> 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?)

Yah, sure, you betcha!

Not at a finer "granularity," I think, but with more information at 
that granularity.  Consider the difference between these two cases:

* merged r123,r125 from REL1 branch into REL2 branch, because I haven't 
thought about r124 much yet

* merged r123,r125 from REL1 branch into REL2 branch, because REL1:r124 
was a really bad idea and I've already fixed that bug in REL2 by a 
completely different approach

A subsequent merge of REL1 head to REL2 head (should at least offer the 
REL1:r124 change in the first case, but should most definitely exclude 
it in the second case.  The granularity is still change set, but the 
assertions are extended to distinguish "not yet merged" from 
"intentionally excluded."

> 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.)

Gosh, I'm sorry I haven't spoken clearly enough ;-)

-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Archiving merge metadata, class project...

[Ben Collins-Sussman <su...@collab.net>]

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