Michael Toal wrote:
> Thanks for the quick response.
> That also worked for me (partially).
>
> What works:
> If
> Person A Updates and then makes change A to the working copy
> Person B Updates and then makes change B to the working copy
> Person A Commits change A.
> Person B Updates in order to incorporate any other users changes.
> There is a conflict because false.bat returned an error code.
> Person B resolves the conflict by hand and then Commits their change.
>
> What doesn't work.
>
> Person A Updates and then makes change A to the working copy
> Person B Updates but does not make any changes yet.
> Person A Commits change A.
> Person B makes change B
> Person B Updates in order to incorporate any other users changes.
> Change A from Person A's Commit is automatically merged into Person B's copy.
Something is wrong with your description. These two scenarios are
identical in Subversion terms.
> What happened was that I was happily making commits to the trunk.
> A colleague Checked Out from a tag from further down the trunk (or an old revision).
> My working copy was synced up with the head of the trunk.
>
> He made changes and then Commited them to the head of the trunk, undoing changes that I had made.
Again, your description is faulty. You simply cannot do that. You cannot
checkout an old revision and then commit it; you have to be updated to
HEAD before the commit will be accepted. Likewise, if you checkout a tag
you cannot commit it back to trunk.
Maybe he made some changes, then updated and got a load of conflicts. If
he then opted to use the entire content of his file rather than resolve
the conflicts properly, that would cause the overwriting your describe.
But in that case the problem was caused by a user doing the manual merge
incorrectly, so your solution of forcing manual merges doesn't seem like
a sound answer.
If you want to take the paranoid approach, a better solution would be to
apply the svn:needs-lock property to every file. That way all files in
the checkout are read-only until you obtain a lock, and only one working
copy can hold a lock at one time, so you are serialising the changes.
This is effectively SourceSafe mode. Personally I don't like it, but
some companies require it.
> I then Updated and it performed an automatic merge.
> If I had to manually merge, then I would have noticed the missing code.
That is perfectly true, but when it happens every time, you soon start
skipping through the changes very quickly. It's a bit like the old DOS
'are you sure?' warnings; after a while you always choose 'yes'
automatically, so it doesn't offer real protection.
> I hope that you can understand that it is difficult to advocate,
> when mistakes like this happen in the trial.
Of course. But mistakes do happen in trials, and they will always happen
while there are humans around. As users become more familiar, those
mistakes will happen less frequently, but they will never go away. If
you find an RCS that is idiot-proof, let us know ;-)
One point to note is that it is very easy to look at the changes made in
a particular revision and undo them if necessary (take a look at the log
dialog, and the context menu for the top pane).
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri Sep 22 23:59:11 2006