bug #898 priority questions (Was "Re: Timeframe for 1.4")

Hello all,

I'm interested in the status of bug #898. My organization will
likewise wait for it to be dealt with (1.4 or later) before converting
from CVS to svn, unfortunately.

- 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
  bugs?

Ted

-- 
 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, 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