> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> Right, but not to the Subversion client, since you need to
> contact the server anyway to get acurate information.
>
> > It is not
> > explicitly made visible to the user at points where it
> would be useful
> > (on update, checkout, etc.)
>
> Right, because at that point of time it's not available to
> the Subversion *client*.
>
> > Instead the user is forced to jump through additional hoops
> when they
> > shouldn't have to.
>
> Yes they should. The word 'accurate' is key here: there's no
> way the client can give the user accurate information. The
> server however can, meaning that - for accurate info - you'll
> always need to contact the server.
Yeah, so? That's true always with everything. Are developers too
stupid to do "update" to get the most accurate state?
>
> > The system should fail "safe" and if
> > it detects a lock on update (or checkout) then it should
> note it and
> > record that in the working copy (which would make it easier for
> > clients like Tortoise to then display the lock).
>
> Nope. It does not and will not. That's by design. The only
> way to get an *accurate* overview is by contacting the server...
Then there is absolutely no point in having a working copy - after all,
the base may not accurately reflect the state of the server, right? I
can't speak for him, but I think giving the developer more information
earlier is better than not doing so. If they want to be stupid about
it, they're no worse off than they are right now. However, if they want
to be smart about it, they have a very useful tool to get a visual
overview of the state of the repository at the moment of their most
recent update.
>
> > If the working copy indicates
> > a lock, even though the lock has been released since the
> last update,
> > that's the "safe" failure as it alerts the user to a
> potential problem
> > before it occurs.
>
> So will having svn:needs-lock, because then the users can't
> modify the file without getting a lock on it first...
Yeah, but that forces serialization all the time. I want to be able to
force serialization for a short time, without creating a property (and
thus two extra revisions: one to add, one to remove). If I add a lock
to a file because I am about to totally rearrange the layout of a
class/module, I am likely to communicate it verbally. However, not
everyone does.
This is an additional level of communication. Standard practice for any
developer is to "update" before beginning any new changes, and update
frequently to avoid merge problems. If this standard practice is
followed, the feature would be valuable. If it is not, it does no
damage.
>
> > The locked status in the working copy would tell the user
> to do one
> > of the following:
> >
> > 1) Go talk to the person who has the file locked.
> > 2) Wait and later try a svn update or status -u on the file
> to see if
> > the lock has been released
> > 3) Choose to break the lock.
> >
> > I'm not advocating putting more restrictions on the file
> modification
> > process. I'm advocating enhancing the existing commands to provide
> > data that is already captured in a manner that is easily
> understood by
> > the end user.
>
> Right, but that data would give the user an incorrect view of
> the situation, because it might suggest to said user that if
> the working copy *doesn't* show a lock, the file will
> probably be unlocked: this isn't correct.
Yeah, so? Right now, the same happens, except there is MORE work
necessary to avoid it. This is a good thing? If the user does an
update, like they're SUPPOSED to do, they would become aware of the lock
immediately. Now, she has to do an explicit "show me the server status"
command, and that information is not stored with the working copy, so
they either have to remember which files are locked (maybe write it
down) or keep checking the server on every file they want to edit. It
gets worse if they don't want to lock it, because now they have to do it
again six hours later when they come back to continue work.
Is resistance to this idea due to a philosophical viewpoint, or is there
some real technical complexity with this?
--
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
Received on Wed Nov 14 14:54:16 2007