2009/6/15 Bryan Lyman <bryan-lyman_at_leavitt.com>:
> Version and Platform:
>
> TortoiseSVN 1.6.2, Build 16344 - 32 Bit , 2009/05/09 13:46:29
>
> Visual Studio C# .net code text
>
> Actual Situation:
>
> Programmer A is coding working on the same file as Programmer B. Programmer
> A commits his changes as revision 4. Programmer B finishes what he is
> working on and wants to merge his changes to those made by Programmer A.
> Before committing his changes, Programmer B “Updates” from the repository
> and finds that he has some conflicts which must be resolved during the
> merge. Programmer B resolves all conflicts and marks the files as resolved;
> he then decides he doesn’t want to commit his changes just yet, so he
> continues working. Later Programmer B decides it is time to finally commit,
> but he would like to do another update to make sure his new changes don’t
> conflict with the same revision as before (Programmer A has not checked in
> any new changes). The update reports that he is already updated to the
> current revision and there were no conflicts, so he determines that it is
> safe to commit his files and does so as revision 5.
>
> Programmer A has been working all the while and decides to get the latest
> changes made by Programmer B; he does so and gets no merge conflicts. When
> he opens his code he notices that his changes appear to be new changes made
> by Programmer B merged with what appears to be Revision 3.
What do you mean by this statement? If you look at a file in a text
editor you cannot tell who made which changes when and relative to
what. You only see the state of the file as it is now. Are you saying
that Programmer A notices that his changes have gone? If so then
Programmer B has messed up the conflict resolution and discarded A's
changes.
> To recover
> specific files he must go into the log history and revert those files from
> revision 5 to 4 and have Programmer B try manually merge what changes he can
> remember from revision 5.
Yep, that is consistent with B having done it wrong and elected to
keep is own changes in favour of A's, rather than merging them.
Possibly B used "Resolve using mine" which would just discard all A's
changes that conflicted with his own.
> Observed Behavior:
>
> The basic behavior should be that when Programmer B updated to revision 4,
> it would attempt to merge revision 4 with his working copy.
That is not an observed behaviour.
> But it appears
> that only files not in conflict updated to this revision while those that
> used Diff to resolve conflicts retrieved an older revision to merge with the
> current working copy.
What do you mean by "those that used Diff"? There is no automatic
reoslution of conflicts, It was B who used a Diff/Merge program and
told it what to use.
> Also, using update after it has already been updated
> once is expected to re-compare files that are currently modified. Instead it
> appears that once the files are marked as having been updated to revision 4,
> they will never again compare because they are marked as already having been
> updated to revision 4.
You can't just compare a file. You have to compare *with* something
and you don't say what they are actually being compared with and what
you expect to be compared with.
> Expected Behavior:
>
> An update run more than once should again compare any files which are
> currently being modified to make sure that any new changes since the last
> update are not in conflict with the current revision.
That is exactly what happens. If you diff a file after it has been
updated to r4 then the diff is against r4. It is not against the state
of the local file when you last did the update, it is against the
state of the file as it exists in the repository at r4.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2362379
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-06-16 10:33:27 CEST