resolving tree conflicts
Niemann, Hartmut
Hello!
Can anybody help me understand how resolving tree conflicts should be done?
A coworker has moved some directories around.
Now I updated my working copy and got around 15 tree conflicts.
I have no easy way of resolving tree conflicts from the update dialog, which would be really nice if it was possible.
After closing the update dialog, I choose “resolve” from the menu.
I see “Status” is “added(+), tree conflict” which is odd, because nobody added them recently in my working copy,
but someone removed them from the server.
I choose “undo add” from the context menu and am asked “do you want to revert <dirname>”?
I find this odd for two reasons.
(1) I chose “undo add” and am asked to confirm action “revert”.
(2) I ‘revert’ a change and I ‘undo’ an add, but in this case,
neither is actually what I do. I would prefer an action along
“accept the server side by removing everything that was unchanged in WC and remove all the rest from the
working copy database (with a choice between removing it from the file system or keeping it as “not under version control”?)”.
On files, i can (IIRC) chose “resolve conflict using “theirs”” and get what I want.
What is the best way of resolving such tree conflicts? Can the situation be improved
or is it just me who doesn’t understand how it works?
Mit freundlichen Grüßen
Dr. Hartmut Niemann
Siemens AG
MO MLT LM EN CCI 1
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel.: +49 9131 7-34264
Fax: +49 9131 7-26254
mailto:hartmut...@siemens.com
Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm,
Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
Niemann, Hartmut
Hello!
Follow up question:
If in the process of cleaning this mess a reference to an external gets stuck: how do I clean it up?
D:\PRJ\Tools\040_python\020_Tools>svn status SG_LINT
X SG_LINT\030_Src\lib\sg
Performing status on external item at 'SG_LINT\030_Src\lib\sg':
D:\PRJ\Tools\040_python\020_Tools>
The directory “SG_LINT” is one of those which do not exist any longer in HEAD.
How do I get rid of the external entry?
Mit freundlichen Grüßen
Dr. Hartmut Niemann
Siemens AG
MO MLT LM EN CCI 1
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel.: +49 9131 7-34264
Stefan Hett
Hello!
Can anybody help me understand how resolving tree conflicts should be done?
A coworker has moved some directories around.
Now I updated my working copy and got around 15 tree conflicts.
I have no easy way of resolving tree conflicts from the update dialog, which would be really nice if it was possible.
After closing the update dialog, I choose “resolve” from the menu.
I see “Status” is “added(+), tree conflict” which is odd, because nobody added them recently in my working copy,
but someone removed them from the server.
Since the "moved"/old files were still present in your working copy, TSVN took that as you want these files to be kept there. Since they were gone on the server, that translated to an add of these files.
I choose “undo add” from the context menu and am asked “do you want to revert <dirname>”?
I find this odd for two reasons.
(1) I chose “undo add” and am asked to confirm action “revert”.
(2) I ‘revert’ a change and I ‘undo’ an add, but in this case,
neither is actually what I do. I would prefer an action along
“accept the server side by removing everything that was unchanged in WC and remove all the rest from the
working copy database (with a choice between removing it from the file system or keeping it as “not under version control”?)”.
On files, i can (IIRC) chose “resolve conflict using “theirs”” and get what I want.
What is the best way of resolving such tree conflicts? Can the situation be improved
or is it just me who doesn’t understand how it works?
In principle here's how I handle tree conflicts during an update due to modifications in files in my working directory due to the files being moved.
1. For all tree conflicts I select: "Resolve later" in the conflict resolution dialog which pops up during the update.
2. I check out the files which got moved and their new location.
3. I use Winmerge to compare my version of the file in the old location with the file in the new location and port over all changes I want.
4. I remove the old files using TSVN -> Delete (context menu)
5. The conflicts should now have been marked automatically as resolved and I'm all fine.
Note that this is just one use-case... I'm going with different approaches for different use cases, but this one is one of the most common ones.
Hope that help.
-- Regards, Stefan Hett
Stefan Hett
given your previous message I take it that you did some local changes to some of the files in that external directory and therefore it had problems upon update.
Another situation might occur when you use certain older TSVN/SVN versions which had some difficulties under certain circumstances to deal with incoming removal of externals to the WC. To make sure that's not the case, I suggest you either run 1.9.3+ or 1.8.14+ based SVN versions of TSVN.
The easiest way to resolve that can be:
- save all the changes you have in ur WC in the external folder and it's parent folder somewhere
- remove the parent of the external
- do an update
- reapply the changes
Note: externals are handled via SVN properties on the parent directory of the actual external. If there's a conflict/issue on that side, you'd also try to resolve that one and spare you the time of the backup/reapply process I pointed out above.
-- Regards, Stefan Hett
Niemann, Hartmut
Hi Stefan!
Thank you for your answer.
I think you spotted my main problem.
You wrote:
> By choosing "resolve" in that menu, you told TSVN that
> the current state in your working directory is what you like to have to have the tree conflict resolved.
In fact, I wanted to tell TSVN “I want to deal with it now”. This is what “resolve” means to me.
> Since the "moved"/old files were still present in your working copy,
> TSVN took that as you want these files to be kept there.
> Since they were gone on the server, that translated to an add of these files.
This explains it.
But from my perspective onto the workflow it doesn’t make sense.
This behavior does not differentiate between changed and unchanged files.
And it ignores the fact that I was never asked whether I want to add or keep anything.
If a directory is dirty (changed/ignored/unversioned files), it seems to be not touched at all on a removing update,
but I would find it much more logical to deal on a removing update on a file-by-file
basis and remove everything that is clean.
Maybe the state “added” is - although maybe technically correct - misleading.
A file should be “modified, server side gone”, or “unmodified, server side gone”,
and in the latter case it should be removed on update with or without asking.
In my opinion an option to delete everything that was under version control
and unchanged - and leaving the other (changed/unversioned/ignored) files lying around -
would be great.
So a directory is gone on the server, you update,
and all files under version control that were unchanged are removed.
You keep a directory that is marked “not under version control”
with some leftovers.
For all the details of your workflow you wrote: thank you very much, I’ll study them as soon as time permits.
Mit freundlichen Grüßen
Dr. Hartmut Niemann
Siemens AG
MO MLT LM EN CCI 1
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel.: +49 9131 7-34264