Mark Phippard <markp <at> softlanding.com> writes:
> Probably just do an Update. I *think* this will leave the file coming from
> the server as unversioned. You could always do Revert, Update, Delete,
> Commit
I've tested it (an Update) and it definitely is not behaving sensibly:
1. Check out as a project
2. Modify Bar.java and commit as another user
3. Delete Bar.java
4. Sync and find a conflict
5. Update Bar.java. It displays a warning: "you have local changes that
conflict with the server. Update will attempt to merge those changes. do
you want to continue?". Choose "Yes".
6. Bar.java (14) displayed in the sync view becomes Bar.java (BASE). It
becomes from a conflict into an incoming change. The file in package
explorer is marked in error (red cross). The content of the file is the
latest version.
7. Performing an update again will NOT get rid of that incoming change.
8. Try to mark it as resolved in the package explorer. But the red cross
persists.
9. Performing a sync will tell me that no changes found.
10. Modify Bar.java and sync, it will tell me that no changes found.
The corresponding console output is:
checkout -r HEAD file:///c:/repo/prj/trunk
A C:/workspace/SVNTest/Bar.java
U C:/workspace/SVNTest
Checked out revision 13.
delete --force C:/workspace/SVNTest/Bar.java
D C:/workspace/SVNTest/Bar.java
update -r 14 -N C:/workspace/SVNTest/Bar.java
U C:/workspace/SVNTest/Bar.java
Updated to revision 14.
===== File Statistics: =====
Updated: 1
resolved C:/workspace/SVNTest/Bar.java
Of course, performing a revert after a conflict is found works.
> Personally, I would just use the Synch view for status info and compares,
> but then stick with update and commit for the actions. Worst case is that
> update creates a local conflict that you then can resolve using the same
> technique you would have used from the Synch view.
As shown above, the problem here is that after performing an Update,
there is no way to resolve the conflict. I think this is not an
acceptable behavior.
> I am not saying there aren't any problems here I just do not think it is
> entirely clear what they are and what the correct behavior would be.
I'd suggest that:
To perform an Update, it should put the latest content into Bar.java
with markers. It should create Bar.java.old-release# and
Bar.java.new-release#. The user needs to mark the file as resolved
before he can commit.
Instead of performing an Update, the user may mark the file as merged
in the sync view. If the user leaves the file as non-existing, it means
to delete it. If the file exists, it means to to use it as the merged
version.
If the above behavior is too hard to implement, you may consider to
simulate the behavior of the command line client:
To perform an Update, it will create an unversioned Bar.java. The user
must mark it as resolved before he can commit.
Received on Sun Nov 13 16:05:46 2005