Simon Large wrote:
> Hi folks,
>
> I am starting to think about documenting the merge tracking features
> and need some pointers.
>
> In the log dialog there is a checkbox to include merged revisions, and
> in the context menu in the top pane there is an entry 'get merge
> logs'. These seem to do the same thing, in which case the context menu
> seems an inappropriate place.
Moved the entry 'down' to the changed paths list - I don't know why I
put it in the revisions part...
> 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'.
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.
fully recursive: the same as 'recursive' in 1.4.x
immediate children, including folders: for folder A, this means that all
files within that folder are affected, and all folders inside A, but not
beyond that. A\B\file won't get affected because that's already inside a
*sub* folder.
Only file children: affects only the files within the folder. In folder
A, all files are affected (A\file1, A\file2), but not the folders (A\B
is not affected).
Only this item: for files: the file itself is affected. For folders:
only the folder properties are affected, no files or folders inside that
folder.
> Are any other dialogs affected?
Almost all which have to contact the repository.
> 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). 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).
> 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.
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.
Stefan
--
___
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
Received on Sun Sep 2 11:35:00 2007