> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
>
> > Interesting. What happens when a person gets a lock on a
> file while
> > another person begins working on his own local copy? Am I
> correct in
> > believing that the user who doesn't have the lock will do his work
> > oblivious to the new lock until he attempts to commit?
> What happens
> > if the person who has the lock made changes that make the second
> > person's work totally useless?
>
> If you're using svn:needs-lock, the file will be read-only
> for that user until either they manually unset the read-only
> bit (or their software ignores it) or they claim a lock on
> the file for themself.
I'm refering to the case where normally, operations are not locked down,
but a user locks the file with the expectation that they will make major
changes.
>
> > It seems to me that it would be useful to know this with a quick
> > "update" operation. Keep in mind that I'm looking at this
> through the
> > eyes of joe (microsoft) developer who is using an IDE integration.
> > Many of them are a bit more "lazy" when it comes to SCM.
> They don't
> > want to execute a "list all changes on the server" operation. They
> > want to see a visual notification that something
> interesting changed
> > ("oh, gee, with this update, the file I'm editing suddenly has a
> > padlock on it! I wonder who did that?").
>
> Sorry, but I think at some point, the developer has to take
> responsibility for his own actions. You can only hold his hand so far.
> It does not take that much effort to check for locks on the
> server beyond checking the status of your working copy in the
> first place. If you're properly using svn:needs-lock and your
> software properly obeys the read-only attribute, this really
> isn't a problem.
Your point is the one I make, but that doesn't mean it will be accepted.
>
> > Granted, the individuals who may or may not be giving me a
> hard time
> > for the lack of this notification, might not want to do
> even the work
> > I'm suggesting. There are some people who expect the server to be
> > pushing out information all the time.
>
> Then those expectations need to be reset. Subversion just plain
> *doesn't* "push" information out all the time. It's a pull system.
Yes. Remember, though, I am evaluating different packages for adoption,
so it will come down to "reset the expectations" or "this isn't for us".
This is the reason for my probing questions.
> -----Original Message-----
> From: Rainer Sokoll [mailto:R.Sokoll@intershop.de]
> > want to execute a "list all changes on the server" operation. They
> > want to see a visual notification that something
> interesting changed
> > ("oh, gee, with this update, the file I'm editing suddenly has a
> > padlock on it! I wonder who did that?").
>
> TSVN has its own overlay icons, it is easy to see which files
> are r/o and for wich files the user has a lock.
> The same for Subclipse, others I do not know.
>
> Rainer
Well, yes and no. I verified that TSVN (and Ankh) only shows an overlay
for items locked by the workspace that initiated the lock, which lead to
my initial post. There is no information available by standard "update"
that would let TSVN choose an icon to identify the state as defined by
OTHER users. This is why I suggested the information be included in the
workspace update info.
--
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 Mon Sep 17 17:56:57 2007