[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 09:11:14 CEST

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

> Jack Repenning wrote:
>> This all depends on having svn:merged props to record the merge history.
>> But is there always somewhere to park that property when you need it?
>> Something here I'm not quite following, probably because I haven't fully
>> grokked a more basic question ... So I'll ask that one:
>> If you merge a URL into your WC, some files will change and others will
>> not. Can you attach a new svn:merged to all the files in the WC, even
>> the unchanged ones, without losing any existing svn:merged?
> If the file didn't change, you don't have to record any merge history.
> You can, of course, and it doesn't hurt, but it's not necessary to the
> proposed algorithm.

Right. For consistency I was thinking to always record the merge in
svn:merged-from, even on unchanged files. Then again, we do not
need it and it is unrequired overhead...

There is a use case for recording svn:merged-from for files that haven't
changed though. We might want to tell merge we want to sync up to
branch@Y (MRMR = branch@X), but to ignore all changes. This way you
can avoid certain changes on 'branch', since next merge will be from
branch@Y to branch@HEAD, effectively bypassing the changes in
branch@X:Y. And yes, we do need an extra switch to pass to svn merge
for that. Ofcourse you can argue that this use case does have changed
files, namely on branch (MRMR:L), instead of the working copy (M:WC).


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