RE: Re: Timeframe for 1.4

From: Andy Peters [mailto:devel@latke.net]

>> 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!!!
>>>
>>>
>Why not use locks? This is one advantage to checking out directories and
>not individual files. The first person to check out the workspace locks the
>whole thing and can make changes as necessary. When the changes are
>committed (including the file rename) and the lock released, then the second
>developer gets to do whatever is needed.

Ugly. Why would we want to lock an entire directory, for fear of someone wanting to rename a file? This is worse than even RCS--at least that only prevents concurrent development on the same file!

The point is, Subversion claims to support renaming files; unfortunately, it only does so half-way: if you move a file, it's previous log history is maintained, which is good--but any concurrent development is horribly, horribly broken (as the original poster pointed out). Now, I really like Subversion--but this one bug is remarkably broken, in my opinion, and should never have made it into the 1.0 release. Personally, I feel that the dev team should've either fixed this bug, or not claimed to support file renames. Either option would be very preferable to the current "Well, we support it, but only if you don't have anyone else working on the file, or any concurrent branches, or blue eyes, or..."

-David
Received on Fri Jan 13 21:01:25 2006