Edward Harvey wrote:
> It's easy to do an update on the top level tree, before going into the
> tree and I have instructed all the users to do this.
Good.
> This step is sufficient, I believe, but it does not give the user any
> information about file locks. So, in the current model, the users are
> also required to check for modifications after doing the update. It
> seems like this is extra work that shouldn't be necessary. Automation
> is the strong point for computers, and the weak point for humans.
Automation is only good if it's absolutely 'reliable'. With reliable, I
mean there must not be the slightest possibility for the information to
be wrong or outdated. If it is, then automation just makes the user
*think* he's save to do something, even if he might not be. And that's
even worse than no automation.
> Also, when you check for modifications, it will merely present a list of
> files that have locks, and if you have dozens of people working on
> files, there will probably be dozens of files that have locks, and from
> the perspective of the engineer, they have to ask themselves, "Will I
> need to work on any of the files in this list." And simply remember
> which files have locks by other people.
It is important for people to remember which files are locked by others.
At least for those files they're working on or plan to work on.
Otherwise, your people don't even know what others are working on, and
they then might work on the same thing, or things that interfere with
each other. You must keep your people informed, if they can't remember
that, then your whole project is doomed anyway.
> I think it would be a lot easier if only a person could see that a file
> was locked, before they try to edit it.
>
>> There is supposed to be a mechanism in subversion
>> (svn:needs-lock) which will help enforce this... Have you used that?
>
> Yes, I've looked at needs-lock. The concept is good, but in practice,
> it's no fun to use. If everything worked smoothly (which it doesn't)
> then it would require users to always get locks, even if they know
> nobody else will work on a file. And everytime they create a new file,
> they have to apply the needs-lock on it, and simply this creates
> additional work for the users. Instead of being able to simply notice
> that someone else has already got a file locked.
You can set the autoprops in the Subversion config file to always set
the svn:needs-lock property on added files automatically.
>> I noticed that Tortoise adds a SVN Lock owner attribute to
>> the explorer window. But in my lock tests I do not see this
>> value getting populated even after an update, even after
>> doing a manual check for modifications/check repository which
>> shows the lock. How can I get this column to show the current
>> lock owner?
>
> I've noticed this too. If anyone knows anything about this one, I'd
> like to know too.
It shows you the locks present in the working copy, i.e. your own locks.
Subversion does *not* store locks held by others in the working copy, so
they're not shown.
> An additional point -- If you simply go to "Properties" of a file, and
> look under the "Subversion" tab, the lock owner never gets populated.
> Maybe a bug.
You can't set the lock owner. That's not a working copy property. It is
a rev prop, and only present in the repository.
The lock owner is set when you get a lock on a file.
If you really need to know who has a lock on a file and don't want
Subversion to merge your files on an update, then maybe you should use a
different version control system. Some people just aren't comfortable
with the copy-modify-merge model Subversion uses. But you can't expect
us to change the model Subversion is based on just because you want it.
There are other version control tools out there which use the
lock-modify-unlock model exclusively (e.g. Visual SourceSafe - good luck
with that).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Tue Apr 25 21:26:02 2006