Re: Re: Feature / Bug - File lock icon, checking for modifications

Edward,

On 26/04/06, Edward Harvey <eharvey@chilsemi.com> wrote:
>
> If I globally require all files to always need lock, that means a user
> can never edit a file unless they first acquire a lock.

No, just make it so that only those file types that cannot be merged
automatically get the svn:needs-lock.

This makes perfect sense if the user is going to edit a file for a long
> time, but it is an added inconvenience whenever they will edit a
> one-liner.

Other version control systems also force you to lock before you can start
working on the file, so how's that an added inconvenience in (T)SVN?

In general, users should 'update' their working copies before working on
files anyway. If they don't they risk working on stale files anyway. At the
moment if you do a 'Get Lock...' this will either grant you the lock or tell
you if the file is stale (i.e. needs an update) and asks if you want to
update and try getting the lock again.

> It is more user-friendly if I don't force users to obey my policies.

Granted, but the workflow you are suggesting kind of disagrees with the SVN
philosophy. As stated before by others in this thread: SVN favors the
copy-modify-merge approach instead of the lock-modify-unlock approach.

BTW: If your wish was granted and remote locks would be visible in your
working copy then you still have no guarantee that people won't both be
working on the same file: as long as the lock has not been set, both can
work on the file... Only when the first of them actually sets the lock prior
to his update will the other be notified of the lock... The only solution
would be to force them to lock BEFORE they start modifying the file.

--
Regards,
Jean-Marc
----------------
    ___
   // \\  @@     "De Chelonian Mobile"
  / \_/ \/._)    TortoiseSVN
<\_/_\_/ /      The coolest Interface to (Sub)Version Control
  /_/   \_\      Check out http://tortoisesvn.org