William Uther <will+@cs.cmu.edu> writes:
> When you merge data into a file, the merge occurs normally except for
> the svn:merge property. The svn:merge property is not merged, but
> instead a single line is appended to it:
>
> rev-A URL-A rev-B URL-B
>
> rev-A is the start rev of the merge (or * if this is an 'add with
> history' merge - the file didn't exist in revA)
>
> URL-A is the start URL of the file that was merged (this is a * if
> rev-A
>
> is a *)
> rev-B is the end rev of the merge
> URL-B is the end URL of the file that was merged (use relative URLs so
> that, if the repos moves, nothing breaks)
>
> 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.
Doesn't setting svn:merge on every file affect the complexity at
commit time?
My understanding is that at present such files are identical to the
files they were copied from, they are the same node in the subversion
file system. When you commit such a merge no new nodes have to be
created for the files. If you change a property on the copied files
then you will need to create new nodes in the subversion filesystem.
Imagine tagging the trunk, at present a single new directory is
created. With your scheme we will need to create a new version of
every item in order to change the svn:merge property!
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 9 18:42:52 2002