On Fri, Oct 24, 2008 at 9:30 PM, Harvey, Edward <Edward.Harvey_at_patni.com> wrote:
> The fundamental difference between perforce's locking scheme, versus svn's
> merging scheme is mergability. Multiple svn users want to simultaneously
> edit the same files and allow the merge to take place whenever possible.
Huh? I've been using p4 for 3 years now, and I've *never* seen anyone
use it in lock-modify-lock mode (a la Visual Sourcesafe). It uses the
same copy-modify-merge model as CVS and SVN. At least, that's all
I've ever seen. That's why it has fantastic interactive conflict
resolution, and why we imitated it. :-)
> 3. Let there also be a "needs-edit" property, which behaves similarly to
> the needs-lock property: The file is read-only until "svn edit." Then the
> file is read-write, but there is no repository lock. "svn status" will
> assume a file is not locally modified if it has the needs-edit property and
> hasn't been "svn edit"ed
This seems needlessly complex, and forces *everyone* on the project to
either use the 'svn edit' feature or not. It's much more elegant to
make the feature a mode that each user can choose for themselves:
probably an option to 'svn checkout' which activates this "everything
is read-only" mode.
You're right that the existing "needs-lock" property sort of reflects
the behavior we want, but in that case we really *do* want to dictate
that absolutely every project member play along, since there's a real
risk of wasted time when people aren't taking strict turns editing a
binary file. When it comes to a hypothetical 'svn edit' feature,
though, nobody should need to know whether I'm choosing to work that
way or not; it should be a private run-time behavior I choose for
myself.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-25 05:00:26 CEST