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

Bill

----
Do you want a dangerous fugitive staying in your flat?
No.
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
Tutt;
> Branko Čibej
> Subject: Re: Saving merge history (was: Re: merge should
copy-with-history)
> 
> 
> 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
those
> >>> files are being copied into your working copy anyway.
> >>
> >> The files get copied into the working copy, but they will show up
as
> >> status copied-with-history and unmodified, so only the parent needs
to
> >> 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
that
> > 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
of
> 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)
inefficient
> part is if you create a large subdir on a branch and then merge it
into
> another line of dev.  In this case things are still not that
> inefficient.  The content diffs will all be zero length - In effect
this
> is just storing a node with the svn:merge property for each file.
This
> 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.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org