Re: Merge tracking questions

On 02/09/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Simon Large wrote:
> > Hi folks,
> >
> > I am starting to think about documenting the merge tracking features
> > and need some pointers.
> >
> > In the merge dialog, I don't understand the merge depth setting.
>
> The depth settings (they're now all over the place) have nothing to do
> with merge tracking. They're part of the 'sparse directories' feature.
>
> The depths indicate how deep the operation will go. Think of it as a
> finer grained setting than just 'recursive'.

Ah, OK. That's (mostly) documented already in update-to-revision and checkout.

> working copy: I made this the default in most dialogs. All it means is
> that the operation goes as deep as the working copy is. Usually, that's
> fully recursive. But if you checked out a working copy with a different
> depth (e.g. you only want the folder itself, not all subfolders too),
> then the operation itself will then use that depth. For update that will
> mean it won't fetch the 'missing' folders but only update what's already
> there. For merge, this means the merge won't pull in files/folders
> outside the already present files/folders.

Shouldn't this option be available in update-to-revision as well?

> > Are any other dialogs affected?
>
> Almost all which have to contact the repository.

I meant are any other dialogs have changed function due to merge tracking?

> > I will have to update the merge description where it talks about the
> > repeated merge problem, but do we need any more information in the
> > manual?
>
> I don't think so. But we have to document the sparse directories feature
> (the ones dealing with depths).

I will review. Maybe this needs a separate page cross referenced from
several places.

> Merge tracking is done mostly behind the
> scenes, but there are of course some things that are visible:
> * log dialog
> * blame
>
> Don't forget to document that the log cache is only used for 'normal'
> logs (without merge info) because the merge info isn't cached (not
> possible right now because it would take way, way too long to get that
> data).

OK.

> > Client/Server compatibility probably comes into play somewhere.
>
> Yes, for servers <1.5.x, some of the merge tracking features won't work
> fully. For example, the new blame (try a very recent nightly build): it
> will show the *merged* lines and that information (it's not really
> useful to know that a line got changed in rX just because it got merged
> - what's really interesting is the merged revision rY and that log).
> When you get the blame info from a < 1.5.x server, the merge info is
> incomplete: the revision/author/log message is still from the merge
> itself. Only the path is shown (menu entry to activate the path column).
> However when you talk to a >= 1.5.x server, the correct
> revisions/authors/log messages are shown for each line.

Is that a server change or a repo format change with 1.5?

> Please have a look at the merge tracking functional specs:
> http://subversion.tigris.org/merge-tracking/func-spec.html
>
> The "Merge History Audit and Query" has some examples on how the merge
> info is shown with the log and blame commands. You'll get the idea on
> how this works from those examples very easily.

Thanks,

Simon

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org