>--- Forwarded mail from [EMAIL PROTECTED]

>Mike Little wrote:

>       For the file lockers out there, a question or two:

>       I gather you would like to be able to lock individual files 
>       on a per-branch basis, purportedly to prevent concurrent
>       editing.   Well, that implies you would like to concurrently 
>       edit the files...otherwise, why the need for _per-branch_ 
>       locking?  So which is it?  And then, when it comes time 
>       to merge the branches? What then?  Well, the files are
>       not mergeable (hence the locks) so I guess you just pick
>       one or the other and throw out the changes on one branch
>       or the other...Well, that's nice.

If locks are needed (i.e. the data in a source file are not mergeable)
then concurrent editing is definitely not wanted.  If it were, then locks
wouldn't be needed.

Also, the fact that the data are unmergeable implies that the notion of
merging branches is meaningless.  After all, if merging were possible,
concurrent editing would be supported and locks would not be needed.

However, there is a large class of situations in which merging reduces
to a selection (copy) of a contributor version.  Yes, it's true that when
working with unmergeable data, you lose certain things that you take for
granted with text files (like merging).

>       So maybe you would like to eliminate branching in order
>       to facilitate locking? 

Absolutely not!  If merges are required, then either selection must
suffice, or the changes must somehow be merged manually without the
use of a specialized merge tool (e.g. by invoking a design tool and
meticulously reimplementing features that exist only on contributor
branches).

>       Ok, these questions are mostly rhetorical I suppose, :-)  but
>       it seems any locking code written would have to address 
>       them in some fashion...

When working with unmergeable data, you end up with degenerate cases of
various computations, but such is the price one must pay when using such
types of source code.  But keep in mind also that the use of such data types
may be compulsory for any of a number of reasons.

>--- End of forwarded message from [EMAIL PROTECTED]

Reply via email to