RE: Re: [BUG] Merging to a branch with sparsely checked out files fails without error

> I recall that too, but can't find it. Anyhow, the way it works is:
>
> "The default depth of a merge is the same as the merge target."
>
> For example, if you don't specify a --depth and merge into directory
> that was checked out at depth=immediates, then the merge will proceed
> as if you specified --depth immediates. It won't matter if some of
> the target's children are themselves checked out a a greater depth.

Interesting. However, I do not know if this is obvious to the user. At least it wasn't to me or to any of my coworkers. Can we open a discussion about how this currently works and whether it should be changed or better documented? I see a few potential solutions for preventing future confusion:

1) Change svn merge so that if --depth is not specified, it defaults to "infinity".

This is what I expected svn to do. As a user, when I merge a particular revision (or range of revisions) into my current working copy, I expect the changes made in those revisions to be fully merged. If they are not, I expect to be told so.

This change would have an interesting side-effect. If a user attempts to a merge a revision which changed a file that is not in the user's working copy, that file (or a parent directory to that file) will be marked as conflicted. This might not be a bad thing, and immediately tells the user what went wrong. They can then revert that conflict and commit if that is what they want to do. Or they can check out the files they are missing and redo the merge.

2) Better document the current functionality.

This could done with additional information in 'svn help merge'. Maybe another paragraph at the top? Or maybe a few additional sentences when discussing the depth parameter, specifically stating the default value.

3) Clarify the functionality in the output of 'svn merge'.

a) When performing any merge, a sentence could be printed that describes the operation about to be performed (something like: Performing merge on . with depth=files).

b) When performing a merge, if parts of the revision(s) could not be merged due to a sparsely checked out working copy, 'svn merge' could print a helpful message to the user (something like: The following files could not be updated as they are not checked out in the working copy: ...).

I think I am leaning toward (1) or (3).

- Sebastian Celis

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405550
Received on 2009-03-24 21:14:18 CET