I guess the only thing I can do now is hope for the best ;-) I am just
very surprised that this wasn't addressed earlier or even talked about
more. This is a big issue and it dates from pre-1.0!
Anyway maybe I could offer an incentive to the developer that will fix it ;-)
The situation I am refering is the following:
1. You and I update our workspace at the same time.
2. You rename file test.txt to test2.txt.
3. I edit test.txt
4. You commit
5. I try to commit and get a conflict
6. I update =>
a. test.txt is now local only (no longer in subversion) and is the
exact same file as it was just before I updated.
b. I have a newly created test2.txt from your commit. That file is
in subversion.
Conclusion: my changes were not merged in test2.txt and I have now 2
files instead of one.
To me the update failed. It did not leave my workspace in stable state
so it should have failed. I need to work on finishing up merging my
workspace. But this happened without warnings from subversion!!!
Now scale this up to a rename/move of root directory... Any changes
made in any files underneath will basically have to be merged
manually. All changed files will be in a separate parallel directory
structure. If you are lucky, the next compile will fail. If you are
not lucky, your automated tests won't catch it, you commit anyway and
deliver with missing functionality.
In other words, rename of individual files may be ok if we do small
commits and keep track of what we change. However renaming of
directories is dangerous at best with other people working at the same
time! Worse the renaming may affect every member of the team!
With languages like java that maps directory to logical packaging,
very deep source tree are created and changed constantly.
Clearcase, our current standard, handles this completely transparently
so it is rather impossible to sell subversion over clearcase even
though subversion is far better for a non-complex <20 people project
IMHO.
However I believe subversion handling is worse than CVS's because in
this situation, CVS will make the update fail. It will complain and
highlight a delete/modify conflict (but I am sure you know that
already ;-) CVS is not ideal either since the new location of the
conflicted files is not known so good luck finding them in a large
repository. I still prefer that because the tool fails fast.
BTW there is a related problem with rename/move and revert:
If I move a file and later decide to revert it, the file won't appear
at its original location and I have still a local file where the file
was moved to.
I suppose this is due to the copy+delete nature of moves so both
primitive operations have to be reverted individually. However
subversion been sold as truely atomic, this is REALLY surprising.
Everybody in my team got confused about this (they are coming from
clearcase though).
I hope this helps.
In any case thank you so much for such a wonderful product. I enjoy
subversion tremendously.
In my mind this problem is really the only show-stopper left that
subversion has. I still cannot believe it hasn't been solved yet ;-(
Jacques
On 10 Jan 2006 16:55:39 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> <bibou644-shop1@yahoo.com> writes:
> > After much observing my company finally decided to start using
> > subversion on one project and painfully stumbled over
> > http://subversion.tigris.org/issues/show_bug.cgi?id=898. This is a
> > major road block for us. In an Agile environment where refactoring is
> > done on a constant basis, not supporting true move/rename is just
> > unacceptable. FYI I believe the way it is implemented right now is a
> > step backward from CVS: at least CVS fail fast if I update a file I
> > changed locally and that somebody else moved in the repository! Think
> > about what happens if I rename the top directory of big hierarchy of
> > files that are been changed at the same time! I won't know about it!
> >
> > Having say that we really like subversion (we are using clearcase
> > right now ;-( ) and would still like to use it long term. Is there a
> > timeframe for 1.4? Would the bug be available in a release before
> > that?
>
> Sorry to hear it; we feel your pain. Unfortunately, I don't know
> anyone who can (or is willing) to commit to a schedule for fixing
> issue #898 right now. That doesn't mean it won't happen; it might
> even happen soon, possibly for 1.4 (we don't know 1.4 timeframe yet,
> but it should be less time than elapsed between 1.2 and 1.3).
> However, you shouldn't make business decisions based on it.
>
> (I'm not sure exactly what the "won't know about it" scenario you're
> describing is; maybe you could show an example?)
>
> -Karl
>
> --
> www.collab.net <> CollabNet | Distributed Development On Demand
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 13 00:14:58 2006