On 11/14/07, Bicking, David (HHoldings, IT)
<David.Bicking@thehartford.com> wrote:
>
>
> > -----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.
Ummm, no. Consider this scenario with 2 users both ready to start a
new change, both start by doing an update. They both end up with r10
which is the newest in the repository. There are no locks in the
repository.
So, they both start working on the same file. User B acquires the
lock. User A forgets this, but his working copy doesn't indicate locks
in the repos anyway, so what the heck...
Then they both want to commit. User A notices he should have acquired
the lock and tries to do so, but the file is locked in the
repository.... Why didn't his working copy indicate that?! In the past
he had always had locks indicated to him by his working copy! So,
Subversion must be broken, right?
The scenario above is what we're preventing from happening.
What they're SUPPOSED to do when working on a file which needs locking
is *lock* it. That's the only thing which is going to get them either
a lock or 'already lokced'. Nothing else.
> 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.
Why? Why not just lock the files they need and notice they're not
available? You can do batch lock-requests too... Besides, if you have
the lock hook mail lock releases there's no reason to re-check every
hour. Also, have the colleagues talk to each other helps.
I'm sorry, but you're tying concepts which are not tied: lock is
orthogonal to 'update'; the former is related to write access, the
latter is related to content.
bye,
Erik.
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 14 16:09:43 2007