Ben Collins-Sussman writes:
> Granted, SCM models aren't my area of expertise. But I'd love to hear
someone argue a strong case for lock-modify-unlock. I'd love to hear a
one-sided argument for the other side. :-)
It all depends on what someone is using the repository for. I 100%
agree that for code development a copy-modify-merge approach is better.
But for other work flows a different approach may be better.
For our "source" code base we absolutely want to use the
copy-modify-merge approach. We also have an "editorial" source base
that contains mostly small html "blobs". The editorial folks would like
to have the lock-modify-unlock approach for two reasons.
1) The biggest reason they want the locking feature is that they want to
know who is working on what. If someone has a bug to make a small
change in a exec's bio page - but they see someone else is already
editing that page, they would just assign the bug to that person.
2) Merging English is a little different than merging code. If two
folks make a change in a small textual blob, the it's not like you would
typically just merge those. The flow and semantics of what your trying
to say may force you to rewrite or completely restructure the blob. So
in reality they would never "merge". Rather they would revert and start
over as it would take less time and in the end produce better English.
So if I were to generalize I would say that copy-modify-merge is not as
useful if merge is not an option. The lock-modify-unlock is better in
this case in that it allows folks to avoid the case of having to rewrite
and allows them to know when they need to collaborate with others or
reassign a specific task.
Ray
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 4 19:48:20 2004