On 02/09/07, Stefan Küng <email@example.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
> 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
> > 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:
> 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.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Sep 2 22:54:06 2007