[oops, cc'ing back to the users@ list]
On Feb 15, 2005, at 2:13 PM, Ben Collins-Sussman wrote:
>
> On Feb 15, 2005, at 2:00 PM, Nick Seigal wrote:
>>
>> OK, I am in a development environment with several other developers,
>> they
>> work at different physical locations and communication is not always
>> frequent. There is no change control that prevents two developers
>> from
>> working on the same bug or on working in the same code module (to
>> solve two
>> different problems). On of the tools we used in the past was Visual
>> Source
>> Safe. The transition to Subversion has been mostly good, but we are
>> missing
>> the ability to check to see who has what checked out. This
>> information
>> helps a developer to determine:
>>
>> (a) *which* modules it is OK to start working on,
>> (b) whether there will be merge issues caused by work that is already
>> going
>> on,
>>
>> Given that another developer has a module checked out and there are
>> major
>> differences in it, I may not wan't to also start working on that
>> module
>> until they have tested and committed their changes to the main
>> codeline
>> (e.g. "trunk"). The Subversion paradigm doesn't seem to support this
>> feature, and I was suggesting a way that it could through
>> user-commit-activity statistics.
>>
>> I hope that clarifies...
>>
>>
>
> It does, but to be honest (and no offense intended), this just sounds
> like typical FUD against the CVS/SVN concurrency model. Chapter 2 in
> the book tries to explain the difference between the traditional
> lock-modify-unlock model used by VSS, compared to the
> copy-modify-merge model. I don't want to repeat that section here,
> but go take a look at the major points in there, if you haven't
> already.
>
> Look at Subversion's own development. We have a dozen people working
> on the tree at any time, and often on overlapping areas. Conflicts
> very rarely occur. People have no problems telling each other (either
> via bug-tracker or email) exactly what bugs or code-areas they're
> working on. We generally know who's doing what, and that's more of a
> social engineering issue rather than one to be enforced by locking
> technology. If you really have two developers working on fixing the
> same bug at the same time, then you have bigger problems to worry
> about. :-)
>
> The only time the copy-modify-merge model really falls down is when
> two people try to edit an unmergeable file (like, an image file).
> Somebody commits first, and the 2nd person now has to toss their
> changes completely -- they've just wasted hours on a change.
> *That's* the problem we're trying to solve with the 1.2 locking
> feature. We're not striving to become a universal communication
> system -- that's what email, IRC, bugtrackers are for.
>
> (That said, 'svn status -u' *will* show you which files have changed
> in the server, so you can predict merges and conflicts before you run
> 'svn update'.)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 15 21:19:21 2005