> >
> > > Given the above it makes sense that:
> > > ====================================
> > > 1. A developer who wants to make a change to a file might
> > have to do
> > > extra work if he makes those changes, attempts to commit, and finds
> > > the file is locked. Why? If the locked file is later
> > committed and
> > > completely altered from his base copy, the merge effort is
> > especially
> > > painful.
> > > 2. Said developer has no reason to specifically look for
> > locks, since
> > > the normal modus operandi is to edit, merge, and commit.
> >
> > I'm missing something here. If you are working with content
> > that can't be merged, why is it normal operating procedure to
> > do the work without obtaining a lock? Or in the problem
> > case, why do only some people know to obtain the lock even
> > though other people are working on the same file? Note that
> > if it really is standard procedure not to lock, there won't
> > be any locks for you to see anyway...
>
> Yes, you are missing something here. Refer to #2 that you quoted, and
> also to item #3, which for some reason you apparently didn't get to
> before replying:
>
> 3. A lock is dynamically added to a file presumably due to unusal
> circumstances.
>
> It is possible to choose to lock a perfectly normal file, and there ARE
> valid reasons to do so. To see an example, please go back and read the
> paragraph following that list of points you quoted. When a person does
> this, nobody else knows UNLESS that person decides to send a
> distribution email to tell them, OR the team leader tells the other
> committers in some fashion.
Right. If some file is completely reorganized, the correct way to
handle that situation might *also* (but not exclusively) be to use
locking. The correct way to handle the situation is to notify the team
some major reworking is going on and that the specific file shouldn't
be modified. Sending such notification to some distribution list would
be one of the logical ways to do that.
> At no point - ever - did I imply that these files were "unmergable" or
> had a "requires lock" property. If the file already has a property
> attached that says "you must lock this to edit it", that information is
> CURRENTLY visible in Ankh and Tortoise (immagine that!). Therefore, I
> have no complaints about that particular feature.
>
> All I ask is that MORE INFORMATION which is CURRENTLY AVAILABLE be
> presented to the developers in an easier to use format that requires
> less work to attain. Why is that such a terrible thing? I am becoming
> quite frustrated. Can someone at least acknowledge the points I'm
> making, rather than set up a straw man and set fire to it?
Because it won't solve the use case you're giving us here: if the file
is locked, but it's not usually locked, why should the developer at
all decide to update it and see if it's locked? For normal day-to-day
operations it would be valid for him to start working on the file even
before updating it, because any server side changes will be merged in
anyway.
Further more do your changes still have a very high chance of
presenting developers with the wrong information. This means that very
shortly after introducing this change people will learn to discard the
information presented to them.
Also, there is a lock discovery API which all clients can use (if only
it were by running 'svn status -u' under the hood), so GUI clients
which want to present (up-to-date) locking information can do so by
presenting the latest on the server. These apis are the same for all
clients, so it should be no harder to implement this on TSVN than it
is to do so in smartsvn or any other client out there.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 20 21:39:17 2007