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

RE: Re: Saving merge history (was: Re: merge should copy-with-history)

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-08-09 21:31:25 CEST


Do you want a dangerous fugitive staying in your flat?
Well, don't upset him and he'll be a nice fugitive staying in your flat.
> -----Original Message-----
> From: William Uther [mailto:will+@cs.cmu.edu]
> Sent: Friday, August 09, 2002 12:14 PM
> To: kfogel@collab.net
> Cc: Philip Martin; Nuutti Kotivuori; dev@subversion.tigris.org; Bill
> Branko Čibej
> Subject: Re: Saving merge history (was: Re: merge should
> On Friday, August 9, 2002, at 01:09  PM, Karl Fogel wrote:
> > Philip Martin <philip@codematters.co.uk> writes:
> >> This is what Will wrote:
> >>
> >>> There is one detail that I think is important:  If merge copies a
> >>> directory that didn't exist in revA (ie the dir was added with
> >>> history) then you want to add the merge property to each file
> >>> individually.  This does not affect the time complexity as all
> >>> files are being copied into your working copy anyway.
> >>
> >> The files get copied into the working copy, but they will show up
> >> status copied-with-history and unmodified, so only the parent needs
> >> be committed.  If we set svn:merge on the files then the files will
> >> need to be committed as well.
> >
> > Oh dear, yes.  We should only set the property on the directory that
> > was copied... But of course, that loses some of the usefulness of
> > having the property at all, for example if we're in a subtree of
> > directory later and need to retrieve merge history...
> >
> > Which, now that I think about it, is what led me to the long-ago
> > conclusion that this problem is not simple.  William, thoughts?
> I see the issue.
> - If you just set it on the top level dir, then you lose the info on
> sub-trees.  Bad.
Not necessarily... (more on that in a later email I'm composing)
> - Some form of inheritable properties might be possible, but would be
> tricky.
> - If you set it on each file then you have to make an individual copy
> each file on the server (you are already making these copies in the
> wc) - that copy will be stored as a diff and will have a compact
> representation.
> I think my original proposal is reasonable.  The (slightly)
> part is if you create a large subdir on a branch and then merge it
> another line of dev.  In this case things are still not that
> inefficient.  The content diffs will all be zero length - In effect
> is just storing a node with the svn:merge property for each file.
> is exactly the information you need to store for each file.  And this
> use case doesn't often happen with large trees anyway.
In the short term, Will has it right, since the email I'm composing will
explain the consequences of wanting to do this the right way. ;)
This is the easiest way to do this change now. i.e. make merge non-O(1).
That does royally suck though.
More details in my subsequent email.
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 9 21:32:12 2002

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.