Re: Implementing the Lock->Edit->Unlock cycle

Andreas Krey:

>If you plan doing massive work in a module, you
>need to talk to the other people working in the
>same module anyway, as they would be annoyed if you
>locked the file, and they can't do planned work.

OK.

>Ideally the other people do their commits in small
>increments as well, and you could go and try to
>merge their work to see if that works or starts to
>fall apart. (Even more ideally you'd get notifica-
>tions if other people commit changes that happen in
>parallel to yours, and will need to be merged.)

Those could be implemented via hooks, but how shall
one determine whether a person is currently working
on some file or not, lest he be swarmed by irrele-
vant notifications?

>>As I understand, it requires customization of the
>>svn client so that whenever asked to unlock a file
>>it shall update it also. Is it possible?
>
>No. SVN clients may not even be online at that
>time. Also I would seriously *not* want files to
>change in my workspace e.g under a test run.

But I meant that for locks issued locally via the
working copy.

>Actually, we use svn for such purposes (non-mer-
>gable files), and git for regular sources.

So do you always update and then lock while commenc-
ing work on a non-mergeable file, or do you invoke
this sequence via a single mouse-click or a key-
press?

-- 
Please, do not send replies to the list to my e-mail.