RE: Communication of LOCKS and CHANGES

> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
>
> > Since the feature is useful to all IDE plugins and integrations, it
> > makes sense to consolidate the logic in the core system,
> rather than
> > force all integration clients to implement their own technique (in
> > this case by a combination of "update" and "status -u" and
> proprietary
> > local cache files).
>
> No. Locking is independent of update. There is no reason
> whatsoever to run update on a locked target. It won't unlock
> it - ever.
>
> > Personally, if I see a file I want is locked, the first
> thing I will
> > do is "update" and see if it is still locked.
>
> No need. Stronger: No reason. Locking is independent of
> updating; there simply is no relation other than that they
> may concern the same path in the same (virtual) filesystem.
>
> > Then I can take action or postpone my work.
> > Right now, I don't see that it is locked until I try to
> commit it or I
> > _remember_ to explicitly check for locks.
>
> If a file can't be merged, this is where your error is: your
> workflow conflicts with the type of file you're chaning. You
> need to lock the file before editing it. No need to check for
> locks: 'svn lock' will tell you someone else has the file
> locked already, all this means you're doing *more* work than
> required, not less. If you were to lock the files before
> editing them, instead of "update", "status", "lock",
> "update", you could do with "lock", "update". Clearly this is
> less work.
>
>

Either you are making a conscious effort to misconstrue my use case, or
we're having a serious communication problem. In all my messages, can
you tell me where I either specified or implied that the _reasons_ for a
desire to make lock information available as part of an "update"
included:

1. that I was attempting to lock a file
2. that I was attempting to merge a file
3. that any of the files in question where unmergeable by nature.

I understand that locks are transient.
I understand that locks have nothing to do with revisions.
I even understand that cached lock information might be out of date mere
milliseconds after it is retrieved.

The value I see in making lock information available during a simple
"update" operation stems from these concepts:

1. Many developers use IDE software that have a list of member files and
folders.
2. The status of said files and folders are often shown visibly via
icons on or near the base file icon.
3. Sometimes a developer might need to lock a particular file for any
number of reasons. One such reason is that user is about to embark on a
complete re-arrange of the code in this particular file.
4. The edit-merge-commit model is the primary modus operandi in
Subversion.

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.
3. A lock is dynamically added to a file presumably due to unusal
circumstances.
4. It makes sense for these needs to be known by anyone who might edit
the file.
5. While that should be communicated via standard team methods, it
doesn't hurt to have an alternative mode.

Thus, it seems evident to me, that when a developer does an "update" of
their workspace, it is useful to said developer to see that some files
gained locks, other files released locks. For the ones with locks, it
makes sense to mouse-over the icon that represents said locked file, and
see the description of the lock. For example "I'm re-factoring this
class to eliminate dead code and change the interface entirely", is a
very enlightening message.

Add to that the user id, and you know both who is radically altering the
file, and why. Given this information, if you've not yet started work
on that class, you might decide to:

1) postpone your change until the file is unlocked (talk to the lock
holder)
2) point out to the lock holder that you have a deadline, and negotiate,
possibly bringing in management.
3) send a patch to the lock holder, requesting she merge it in before
things get too hairy.
4) talk to your manager and ask why you weren't told about this work
before you started your task.

Erik, can you explain to me why it makes no sense to make this
information available in a way that is standard across all clients? If
you really cannot wrap your head around doing so as part of an update
operation, perhaps you can construct a new interface that combines the
update operation with the status operation and produces a unified output
and a space in the .svn files to put this lock information. Then,
client software can use this new interface when the end user chooses
"update" in the GUI and reference the new cached information to produce
an appropriate interface in the IDE.

--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org