bug #898 priority questions (Was "Re: Timeframe for 1.4")
From: Ted Stern <dodecatheon_at_gmail.com>
Date: 2006-02-08 22:14:31 CET
I'm interested in the status of bug #898. My organization will
- How do I find out whether someone has been assigned to the bug?
- Bug #898 has 52 votes. How do I see how that compares to other open
-- dodecatheon at gmail dot com Frango ut patefaciam -- I break so that I may reveal On 10 Jan 2006 at 21:32 UTC-0800, Jacques Morel wrote: > 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, firstname.lastname@example.org <email@example.com> wrote: >> <firstname.lastname@example.org> 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: email@example.com For additional commands, e-mail: firstname.lastname@example.orgReceived on Wed Feb 8 23:24:40 2006
This is an archived mail posted to the Subversion Users mailing list.