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

RE: [PROPOSAL] Merging Improved

From: Sander Striker <striker_at_apache.org>
Date: 2003-04-11 00:36:48 CEST

> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Friday, April 11, 2003 12:25 AM

> Sander Striker wrote:
>
>> Not doing tree deltas in the proposal is simply because the same
>> rules apply for them as for normal text files. The merge history
>> can be recorded in the svn:merged-from property on the directories
>> the same way as we do for files. Consider a directory to be a
>> textfile containing filenames ;). [in practice we have real code
>> to deal with tree deltas, but the idea is pretty much the same]
>
> With one caveat: taking tree changes into account will affect the way
> merge history is recorded (see my other post). If you record
> PATH@REVISION[:REVISION], you do get unique keys, but when you're
> comparing merge histories of M and L, you can't tell if they're related
> just by looking at the PATH part.

Ah, yes, ofcourse. Duh.

> I /think/ that recording NODE-ID@REVISION[:REVISION] would be sufficient
> (assuming we have atomc renames that preserve node id's): Perhaps even
> NODE-CHANGE-PK[:NODE-CHANGE-PK], which is semantically the but a) avoids
> one index lookup when pulling the MRCA or MRMR from the repository, but
> b) makes history comparison harder (without making assumptions about the
> strucutre of the NODE-CHANGE primary key).

Going from PATH to NODE-ID is indeed a minimal change to presented
format in the proposal. +1. But, will that also work for out of repository
merges though?
 
> I whish Bull Tutt was here... :-(

/me too

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 00:37:33 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.