You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Oliver Fabelo <of...@canarias.org> on 2008/03/03 10:20:24 UTC
Get exclusive lock
Hello,
I have some colleagues who work with vss and I want change to svn (they are
losing data xD). They use binary files (word documents, crystal reports, .),
and I want that they can work with exclusive locks in svn like vss works .
I've read http://svnbook.red-bean.com/en/1.2/svn.advanced.locking.html (Lock
Communication part). We work under Windows, with svn and Tortoise client.
I've put in each client (in Tortoise config file) that each file was created
with svn:needs-lock property, it works ok. When a user wants write in a
file, he needs "get lock" the file, it works ok too. But now, the problem .
A user, for oversight, can open a file and start to write (the file is in
read-only mode), he forgets "get lock" the file, and when he finishes, he
couldn't write in the file. I want that a user when opens a file (it's with
svn:needs-lock property), it displays a message saying that the file is
read-only and requires "get block". This is the only thing which my
colleagues do not want to go svn . (no comments).
I always say them that each file needs "get lock" for writing in it, but
they say me that they can forget do it . (no comments again xD)
Thanks beforehand.
P.D.: I have svn 1.4.6 and Tortoise 1.4.7.
Cheers.
RE: Re: Get exclusive lock
Posted by Oliver Fabelo <of...@canarias.org>.
Hello,
-----Mensaje original-----
De: Nick.Thompson@infineon.com [mailto:Nick.Thompson@infineon.com]
Enviado el: lunes, 03 de marzo de 2008 13:20
Para: users@subversion.tigris.org
Asunto: RE: Re: Get exclusive lock
You're right in that the user can always save the file somehow, but
ultimately this fails in the described scenario, because the user has
not been told that their changes are useless no matter what they do
next, *IF* some other users has remembered to get the lock and changed a
binary file. Unless the tool used to do this has it's own merge
mechanisms that is.
Really the program being used should either clearly warn you about the
read only status of the file, or refuse edits (unless a save as is done
first).
-----------------------
I wanted to thank all those who have responded to me. I have the "solution",
thanks to a colleague who uses VSS and he has open mind ... (not closed only
to VSS) :-) In VSS, if you does checkout (same that svn with get lock), I
thought that if someone else opened the same document, it is opened and
could not write in it (the colleagues that use VSS said me it), and it is
false, it depends on the program that you use for opening the file. For
example, my colleagues use Ultraedit, for editing files, and Ultraedit
doesn't allow write in the file (because it detects that the file is opened
in read-only mode), but Word, even if the file is in read-only, allows write
in his files (.doc's), don't save, but you can waste time writing in it, so
VSS and SVN, with svn:needs-lock property, behavior is the same (thanks to
Ulrich Eckhardt for his comment too).
I wait that you can understand my bad English :-) Finally, my colleagues
will have to use svn x) I hope that they don't say another excuse ......
Thanks to all.
Cheers...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Get exclusive lock
Posted by Ni...@infineon.com.
> -----Original Message-----
> From: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com]
>
> I know that some programs actually check if a file is
> read-only when opening it and alert the user that they can't
> edit it. Further, even if you are not using such a program
> you can still claim the lock on the file even if you have
> already opened it and made changes to it. There, I know at
> least one program which still refuses to save to the
> now-writable file, so you will have to write to a different
> file first and then copy it over. All of this is not a
> problem but merely an annoyance unless someone changed it before you.
You're right in that the user can always save the file somehow, but
ultimately this fails in the described scenario, because the user has
not been told that their changes are useless no matter what they do
next, *IF* some other users has remembered to get the lock and changed a
binary file. Unless the tool used to do this has it's own merge
mechanisms that is.
Really the program being used should either clearly warn you about the
read only status of the file, or refuse edits (unless a save as is done
first).
Nick.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Get exclusive lock
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Monday 03 March 2008, Oliver Fabelo wrote:
> I have some colleagues who work with vss and I want change to svn (they are
> losing data xD). They use binary files (word documents, crystal reports,
> .), and I want that they can work with exclusive locks in svn like vss
> works .
> [...]
> A user, for oversight, can open a file and start to write (the file is in
> read-only mode), he forgets "get lock" the file, and when he finishes, he
> couldn't write in the file.
I know that some programs actually check if a file is read-only when opening
it and alert the user that they can't edit it. Further, even if you are not
using such a program you can still claim the lock on the file even if you
have already opened it and made changes to it. There, I know at least one
program which still refuses to save to the now-writable file, so you will
have to write to a different file first and then copy it over. All of this is
not a problem but merely an annoyance unless someone changed it before you.
> I want that a user when opens a file (it's with svn:needs-lock property),
> it displays a message saying that the file is read-only and requires "get
> block". This is the only thing which my colleagues do not want to go svn.
You could rebind all relevant file types to some kind of proxy that first
checks if the file is readable before then launching the real editor. I'm not
sure I would like that though, because it means that users who only want to
read a document will then first lock the file even though they don't need it
and of course they will also forget to unlock it afterwards.
I suggest you ask them for a plan where forgetting things does not in any way
cause any inconvenience. I'm pretty sure that no such plan can be made that
is flawless, human errors can't be auto-corrected without severely
restricting educated choice.
> I always say them that each file needs "get lock" for writing in it, but
> they say me that they can forget do it.
What's the difference to the current state that uses VSS?
Uli
--
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: RE: RE: Re: Get exclusive lock
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Nick.Thompson@infineon.com [mailto:Nick.Thompson@infineon.com]
> Sent: Tuesday, March 04, 2008 8:58 AM
> To: users@subversion.tigris.org
> Subject: RE: RE: RE: Re: Get exclusive lock
>
>
> I don't understand how this helps. If I've just spent all day air
> brushing somebody out of a photo, how will being told by Tortoise,
say,
> that I've wasted my time a few seconds or minutes after I save it help
> me? If nobody else has the lock or had the lock, I might get away with
> it, but if another users has got/had the lock and spent all day adding
> a
> UFO in to the background or adding horns and a tail to the person I've
> just air brushed out, this feature gains me little. I will find out as
> soon as I try to commit anyway.
>
> I really need the painting tool to warn me the file is read only/not
> locked by me before I start. Or maybe wrap the tools in a checking
> script that warns the user before starting the tool. This way I should
> be reminded to get the lock and not waste my time editing.
Some of us hit 'alt-f-s' (file save) unconsciously after every minor
change and would benefit from such a feature before too much time was
wasted. =)
A Windows box running the Server service can use 'net file' to see who
has locks on files, if the file is opened over a network share. In
theory, you could share your workspace, map a drive to the share, and
have a script run 'net file' and check for 'svn:needs-lock'. Any apps
would need to access the workspace via the mapped drive or file locks
won't be detected. Putting your subversion workspaces below a
long/silly dir name would help reinforce the need to use the mapped
drive instead.
Or you could get in the habit of automatically saving a file before you
start working on it in order to establish readonly status and/or to give
the 'svn:needs-lock' warning script a chance to work.
Real Solutions would be a Subversion aware painting tool, a painting
tool that respects read-only files property (pops up a message when you
make the first edit,) or something like ClearCase dynamic views which
intercept file I/O calls. However, even something as uber as a
ClearCase dynamic view won't help you from wasting hours on a file if
the painting app doesn't actually warn you that the file is readonly
when you make the first edit in memory.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: RE: RE: Re: Get exclusive lock
Posted by Lasse Vågsæther Karlsen <la...@vkarlsen.no>.
Subversion is not a resident program that works in the background on your
computer, it only runs when you ask it to.
The only way Subversion would be able to warn you about opening up a
readonly file was if it was resident and had some sort of way to tell wether
your 3rd party software is able to detect and warn about this readonly flag
on its own or not.
If your painting tool isn't capable of detecting this and warning you about
it, there is nothing Subversion in its present state can do about it.
Perhaps a 3rd party subversion client would be able to but I suspect this
kind of feature would fall quite far down on the list of things to look
into.
For instance, what if you want to copy the file to somewhere else, or just
view the file? How would Subversion know that this way of opening the file
is "safe" and does not have to be warned about, compared to a painting
program that doesn't detect readonly states?
I think your key sentence is the opening sentence of your last paragraph:
"I really need the painting tool to warn me"...
Yes, you really need your *painting tool* to warn you.
On Tue, Mar 4, 2008 at 2:58 PM, <Ni...@infineon.com> wrote:
> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> >
> > -----Original Message-----
> > From: Reedick, Andrew
> > > In this case, 'svn:needs-lock' is there from the beginning (which is
>
> > > why the readonly flag is set,) and that this is more of a
> > > reminder/warning that one of your Applications changed your readonly
>
> > > file without your knowledge. More importantly, 'svn:needs-lock' is
> > > already being cached by the workspace, so all the lock information
> is
> > > already present.
> ...
> > > A gui client could implement this on their own as a
> > > courtesy feature
> > > without worrying about breaking standards (kind of like how Version
> > > Trees are not standard.) For the command line folks, it
> > > would be more
> > > convenient (and thus more like to be used) if 'svn status'
> > > would flag
> > > any modified, no local lock, 'svn:needs-lock' file.
> >
> > That makes a whole lot of sense. Perhaps something can be
> > implemented then!
>
> I don't understand how this helps. If I've just spent all day air
> brushing somebody out of a photo, how will being told by Tortoise, say,
> that I've wasted my time a few seconds or minutes after I save it help
> me? If nobody else has the lock or had the lock, I might get away with
> it, but if another users has got/had the lock and spent all day adding a
> UFO in to the background or adding horns and a tail to the person I've
> just air brushed out, this feature gains me little. I will find out as
> soon as I try to commit anyway.
>
> I really need the painting tool to warn me the file is read only/not
> locked by me before I start. Or maybe wrap the tools in a checking
> script that warns the user before starting the tool. This way I should
> be reminded to get the lock and not waste my time editing.
>
> Nick.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3
RE: Re: Get exclusive lock
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Tuesday, March 04, 2008 12:15 PM
>
> Reedick, Andrew wrote:
> >
> > Version control doesn't make money, it saves money.
> Anything that can
> > reduce the knowledge/effort needed to use version control is a good
> > thing. In this case, it's probably a good, practical idea
> for key SVN
> > operations to print a simple reminder indicating the presence of
> > 'svn:needs-lock' files in the workspace, to help prevent costly
> > mistakes.
>
> Remind me here... how did the person who created the file
> know to set the needs-lock status in the first place? What
> if you create a similar file? How will you know to set the
> property? If you have people who don't understand which
> files can have changes merged easily and which can't, you
> will not only have people who don't observe the needs-lock
> property, you aren't likely to have it set on the files that
> need it anyway - unless the people who edit files don't
> create new ones. Being 'mergable' or not is really an
> inherent property of the file type, not something dictated by
> the VC so you probably want to get a lock any time you plan
> to touch such files whether anyone else remembered to set the
> property in the VC or not.
First, try to explain it, if that doesn't work, just wait. I'll wager
that the first time someone has 3 hours of work overwritten, everybody
will come to understand how, when, and why svn:needs-lock should be
used. Those who don't, probably can't handle the job anyway.
--
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
Re: Get exclusive lock
Posted by Les Mikesell <le...@gmail.com>.
Reedick, Andrew wrote:
>
>> If having svn:needs-lock set really provided that guarantee, this
>> thread
>> wouldn't have started.
>
> Which is the point of the thread. Currently, svn:needs-lock only kicks
> in when:
> a) you app notices the read-only file and communicates that fact
> to the user, or
> b) when you try to commit without a lock, or
> c) when the user explicitly remembers to check for
> svn:needs-lock
>
> a) is weak because not all apps handle readonly files "properly",
> b) is too little too late,
> c) suffers from 'even experts make mistakes' with the added bonus of
> being newbie un-friendly. Plus people who create unmergeable files are
> probably not coders to begin with (pictures, video, audio, etc.) and
> wouldn't even be familiar with the concept of merging.
>
> Hence the desire to add additional notification about, and monitoring of
> 'svn:needs-lock' files by the client.
And my point is that this isn't enough and it won't solve the problem
for people who don't already understand the issue because they won't
know to set it on new files. And if you understand the issue you'll know
to lock files where needed without something that tries to enforce it
(because you know you'd need to set needs-lock on that type of file if
you created it and you know someone else might also be working on it).
>> I'm just not convinced that this mythical "other person" or his tools
>> will be any more observant of a needs-lock status than you are unless
>> he
>> understands the 'guarantee' consists only of your your willingness to
>> cooperate. If you both work at once, one of you is going to lose
>> regardless of how much the tool tries to help.
>>
>
> Agreed. If a knowledgeable person or client was in complete control of
> the situation, then there wouldn't be a problem. However being in
> complete control is impossible unless you either train all your humans
> to be version control experts (and none of whom make mistakes,) or if
> you can force coordination between everyone's OS, their apps, and the
> subversion clients.
>
> So aside from not using unmergeable files anywhere in your organization
> or operating in a police state with total control over everyone's
> computer, the only options are training, and up-front reminders/warnings
> about svn:needs-lock to back-up the training.
Many applications write new files to replace the old as you make changes
and thus don't care if the source has a read-only attribute. You'll
have to replace all of these or write wrappers that generate a warning
(which will only cover the case where you specify the file at startup
instead of using internal functions to open files). Getting the users
to understand the need to cooperate seems like the only real option.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: Get exclusive lock
Posted by Bráulio Marques Horta <br...@gmail.com>.
> Could you let us see your script. I am having basically the same problem and are kinda stuck on the pre-commit hook.
Here it is. I made two versions. One that check for svn:needs-lock
before denying and other that don't check (i.e. force every committed
file to be locked before). I made it using perl and it is called from
my pre-commit.bat.
i had to rename pre-commit.bat to pre-commit.bat$, so if your want to
use it, rename it back.
Pre-commit.bat is for windows, but i think it won't be hard to
translate it to a posix environment.
It's is a quite simple script and probably don't have bugs but i
didn't used it in a real repository, so be care! ;)
Hope it helps!
Braulio
Re: Get exclusive lock
Posted by Bráulio Marques Horta <br...@gmail.com>.
> b) when you try to commit without a lock, or
I made a pre-commit hook script that checks if a file is locked before
committing. We actually don't use this scripts yet and it was not fully
tested, but it worked nicely in some tests we made.
It blocks any commit of unlocked files.
IMHO, it just helps teaching people that they always have to lock files with
the needs-lock property. People will notice that they didn't locked the file
only during commit.
So if one edits any file and didn't locked it. During commit it will receive
an error message saying "You have to file file XYZ". Then only after locking
the file he can commit it.
Maybe It is not the best solution but helps...
Braulio
RE: Get exclusive lock
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Tuesday, March 04, 2008 6:15 PM
> To: Reedick, Andrew
> Cc: users@subversion.tigris.org
> Subject: Re: Get exclusive lock
>
> If having svn:needs-lock set really provided that guarantee, this
> thread
> wouldn't have started.
Which is the point of the thread. Currently, svn:needs-lock only kicks
in when:
a) you app notices the read-only file and communicates that fact
to the user, or
b) when you try to commit without a lock, or
c) when the user explicitly remembers to check for
svn:needs-lock
a) is weak because not all apps handle readonly files "properly",
b) is too little too late,
c) suffers from 'even experts make mistakes' with the added bonus of
being newbie un-friendly. Plus people who create unmergeable files are
probably not coders to begin with (pictures, video, audio, etc.) and
wouldn't even be familiar with the concept of merging.
Hence the desire to add additional notification about, and monitoring of
'svn:needs-lock' files by the client.
> I'm just not convinced that this mythical "other person" or his tools
> will be any more observant of a needs-lock status than you are unless
> he
> understands the 'guarantee' consists only of your your willingness to
> cooperate. If you both work at once, one of you is going to lose
> regardless of how much the tool tries to help.
>
Agreed. If a knowledgeable person or client was in complete control of
the situation, then there wouldn't be a problem. However being in
complete control is impossible unless you either train all your humans
to be version control experts (and none of whom make mistakes,) or if
you can force coordination between everyone's OS, their apps, and the
subversion clients.
So aside from not using unmergeable files anywhere in your organization
or operating in a police state with total control over everyone's
computer, the only options are training, and up-front reminders/warnings
about svn:needs-lock to back-up the training.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Get exclusive lock
Posted by Les Mikesell <le...@gmail.com>.
Reedick, Andrew wrote:
>
>> Being
>> 'mergable' or not is really an inherent property of the file type, not
>> something dictated by the VC so you probably want to get a lock any
>> time
>> you plan to touch such files whether anyone else remembered to set the
>> property in the VC or not.
>
>
> True, but in such a case, the lock is useless, where useless == not
> guaranteed:
> 1) I checkout the file on Monday,
> 2) you lock the file on Tuesday, and
> 3) I try to check-in on Wednesday...
> 4) I break your lock because I'll be damned if I'm going wait
> for you to finish, and then re-do two day's worth of work.
>
> Unless svn:needs-lock is there from the start, there's no guarantee that
> someone else isn't already working on the file, and there's no guarantee
> he'll ever find out about your lock until it's too late.
If having svn:needs-lock set really provided that guarantee, this thread
wouldn't have started.
I'm just not convinced that this mythical "other person" or his tools
will be any more observant of a needs-lock status than you are unless he
understands the 'guarantee' consists only of your your willingness to
cooperate. If you both work at once, one of you is going to lose
regardless of how much the tool tries to help.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Get exclusive lock
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Tuesday, March 04, 2008 12:15 PM
> To: Reedick, Andrew
> Cc: users@subversion.tigris.org
> Subject: Re: Get exclusive lock
>
>
> Remind me here... how did the person who created the file know to set
> the needs-lock status in the first place? What if you create a
similar
> file? How will you know to set the property? If you have people who
> don't understand which files can have changes merged easily and which
> can't, you will not only have people who don't observe the needs-lock
> property, you aren't likely to have it set on the files that need it
> anyway - unless the people who edit files don't create new ones.
Meh, that's a problem with all version control systems when dealing with
unmergable files.
Either train the users, or have the admin pick up the slack.
Subversion's config file can go a long way to automatically flagging
files as 'svn:needs-lock' however, it's a pain to push the config file
to the clients. (I would really like a client side hook to update
peoples' config files.)
> Being
> 'mergable' or not is really an inherent property of the file type, not
> something dictated by the VC so you probably want to get a lock any
> time
> you plan to touch such files whether anyone else remembered to set the
> property in the VC or not.
True, but in such a case, the lock is useless, where useless == not
guaranteed:
1) I checkout the file on Monday,
2) you lock the file on Tuesday, and
3) I try to check-in on Wednesday...
4) I break your lock because I'll be damned if I'm going wait
for you to finish, and then re-do two day's worth of work.
Unless svn:needs-lock is there from the start, there's no guarantee that
someone else isn't already working on the file, and there's no guarantee
he'll ever find out about your lock until it's too late.
On the plus side, I think we finally have a case where DRM would be a
good idea... ;-)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Get exclusive lock
Posted by Les Mikesell <le...@gmail.com>.
Reedick, Andrew wrote:
>>
>> No, you just need to get the lock. Nothing else is going to be able to
>> guess what you are about to do and advise you how to go about it.
>>
>
> Guess, no. Advise, yes. The most practical time to advise the user
> that their workspace contains 'svn:needs-lock' files is during 'svn co',
> 'svn update' and 'svn status', which SVN does not do at this time. Then
> it's up to the user to grab locks on the files they plan to work on.
>
> Version control doesn't make money, it saves money. Anything that can
> reduce the knowledge/effort needed to use version control is a good
> thing. In this case, it's probably a good, practical idea for key SVN
> operations to print a simple reminder indicating the presence of
> 'svn:needs-lock' files in the workspace, to help prevent costly
> mistakes.
Remind me here... how did the person who created the file know to set
the needs-lock status in the first place? What if you create a similar
file? How will you know to set the property? If you have people who
don't understand which files can have changes merged easily and which
can't, you will not only have people who don't observe the needs-lock
property, you aren't likely to have it set on the files that need it
anyway - unless the people who edit files don't create new ones. Being
'mergable' or not is really an inherent property of the file type, not
something dictated by the VC so you probably want to get a lock any time
you plan to touch such files whether anyone else remembered to set the
property in the VC or not.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Get exclusive lock
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Tuesday, March 04, 2008 10:54 AM
> To: Nick.Thompson@infineon.com
> Cc: users@subversion.tigris.org
> Subject: Re: Get exclusive lock
>
>
> No, you just need to get the lock. Nothing else is going to be able
to
> guess what you are about to do and advise you how to go about it.
>
Guess, no. Advise, yes. The most practical time to advise the user
that their workspace contains 'svn:needs-lock' files is during 'svn co',
'svn update' and 'svn status', which SVN does not do at this time. Then
it's up to the user to grab locks on the files they plan to work on.
Version control doesn't make money, it saves money. Anything that can
reduce the knowledge/effort needed to use version control is a good
thing. In this case, it's probably a good, practical idea for key SVN
operations to print a simple reminder indicating the presence of
'svn:needs-lock' files in the workspace, to help prevent costly
mistakes.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Get exclusive lock
Posted by Ni...@infineon.com.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: 04 March 2008 15:54
> To: Thompson Nick (IFGB COM)
> Cc: users@subversion.tigris.org
> Subject: Re: Get exclusive lock
>
> Nick.Thompson@infineon.com wrote:
> >
> >> That makes a whole lot of sense. Perhaps something can be
> >> implemented then!
> >
> > I don't understand how this helps. If I've just spent all day air
> > brushing somebody out of a photo, how will being told by Tortoise,
> > say, that I've wasted my time a few seconds or minutes
> after I save it
> > help me?
>
> I don't see how anything can help until you understand that
> you need to get your own lock _before_ working on a file
> where changes won't merge.
>
> > I really need the painting tool to warn me the file is read
> only/not
> > locked by me before I start.
>
> No, you just need to get the lock. Nothing else is going to
> be able to guess what you are about to do and advise you how
> to go about it.
>
> > Or maybe wrap the tools in a checking
> > script that warns the user before starting the tool. This
> way I should
> > be reminded to get the lock and not waste my time editing.
>
> Maybe it should pop up some photos of your co-workers to
> remind you that other people are involved...
It seems some people think I was auguing for such a feature to be
included. I was trying to point out the futility of adding features that
tell you after the fact that you made a mistake. My point was supposed
to be: IMHO Subversion does all it needs to do today and needs no
change. I do think some other tools *could* be more helpful/cooperative
in not allowing you to change a readonly file, just as a hint. But for
sure, you need to fully understand what the implications of working on a
*team* are: You have to communicate and SVN is a conduit for that - more
fool you if you don't use its features. Nice suggestion about the photos
popping up though - I like that ;-)
Hope that clears things up. Please, don't shoot!
Nick.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Get exclusive lock
Posted by Les Mikesell <le...@gmail.com>.
Nick.Thompson@infineon.com wrote:
>
>> That makes a whole lot of sense. Perhaps something can be
>> implemented then!
>
> I don't understand how this helps. If I've just spent all day air
> brushing somebody out of a photo, how will being told by Tortoise, say,
> that I've wasted my time a few seconds or minutes after I save it help
> me?
I don't see how anything can help until you understand that you need to
get your own lock _before_ working on a file where changes won't merge.
> I really need the painting tool to warn me the file is read only/not
> locked by me before I start.
No, you just need to get the lock. Nothing else is going to be able to
guess what you are about to do and advise you how to go about it.
> Or maybe wrap the tools in a checking
> script that warns the user before starting the tool. This way I should
> be reminded to get the lock and not waste my time editing.
Maybe it should pop up some photos of your co-workers to remind you that
other people are involved...
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: RE: Re: Get exclusive lock
Posted by Ni...@infineon.com.
-----Original Message-----
From: Bicking, David (HHoldings, IT)
>
> -----Original Message-----
> From: Reedick, Andrew
> > In this case, 'svn:needs-lock' is there from the beginning (which is
> > why the readonly flag is set,) and that this is more of a
> > reminder/warning that one of your Applications changed your readonly
> > file without your knowledge. More importantly, 'svn:needs-lock' is
> > already being cached by the workspace, so all the lock information
is
> > already present.
...
> > A gui client could implement this on their own as a
> > courtesy feature
> > without worrying about breaking standards (kind of like how Version
> > Trees are not standard.) For the command line folks, it
> > would be more
> > convenient (and thus more like to be used) if 'svn status'
> > would flag
> > any modified, no local lock, 'svn:needs-lock' file.
>
> That makes a whole lot of sense. Perhaps something can be
> implemented then!
I don't understand how this helps. If I've just spent all day air
brushing somebody out of a photo, how will being told by Tortoise, say,
that I've wasted my time a few seconds or minutes after I save it help
me? If nobody else has the lock or had the lock, I might get away with
it, but if another users has got/had the lock and spent all day adding a
UFO in to the background or adding horns and a tail to the person I've
just air brushed out, this feature gains me little. I will find out as
soon as I try to commit anyway.
I really need the painting tool to warn me the file is read only/not
locked by me before I start. Or maybe wrap the tools in a checking
script that warns the user before starting the tool. This way I should
be reminded to get the lock and not waste my time editing.
Nick.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Re: Get exclusive lock
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Reedick, Andrew [mailto:jr9445@att.com]
>
> > -----Original Message-----
> > From: Bicking, David (HHoldings, IT)
> >
> > >
> > >
>
> The big debate in the 'communication of locks and changes'
> thread was that it was "pointless" to cache impromptu locks
> since the client is "always" out of date. (Impromptu locks
> are locks on files that do not have 'svn:needs-lock', and/or
> other people's locks.)
>
> In this case, 'svn:needs-lock' is there from the beginning
> (which is why the readonly flag is set,) and that this is
> more of a reminder/warning that one of your Applications
> changed your readonly file without your knowledge. More
> importantly, 'svn:needs-lock' is already being cached by the
> workspace, so all the lock information is already present.
>
> All the information needed to determine if you should be
> touching that file already exists, even when you're offline.
> The difference is that it's telling you that you _definitely_
> need to connect to the server and lock the file, whereas the
> other thread was about caching inherently out of date
> information about other people's locks.
>
>
> A gui client could implement this on their own as a courtesy
> feature without worrying about breaking standards (kind of
> like how Version Trees are not standard.) For the command
> line folks, it would be more convenient (and thus more like
> to be used) if 'svn status' would flag any modified, no local
> lock, 'svn:needs-lock' file.
That makes a whole lot of sense. Perhaps something can be implemented
then!
--
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
RE: RE: Re: Get exclusive lock
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking@thehartford.com]
> Sent: Monday, March 03, 2008 2:10 PM
> To: Reedick, Andrew; users@subversion.tigris.org
> Subject: RE: RE: Re: Get exclusive lock
>
>
>
> >
> >
> > Persionally, multi-tasking, windowed OS clients like
> > TortoiseSVN should have an option to periodically check for
> > 'needs-lock' files that have been modified without a lock.
>
> Yeah, so do I, but that's very similar to "communication of locks and
> changes" (because the fact that the file needs a lock has to be stored
> locally - though I suppose you could get that from the file
> properties),
> which was a long debate a few months back about "regular" locks.
> Client
> software teams such as Tortoise aren't interested in creating their
own
> proprietary caching and communication mechanisms - they'd rather have
> the core software handle that. Caching lock status locally or
> regularly
> pinging the server for lock status is, according to the Subversion
> team,
> "right out". I feel that having client software automatically
querying
> the server is a bad idea, anyway, because it increases network traffic
> and demand on the server.
I remember that thread. However... this is Different(tm). We never
talk to the server.
The big debate in the 'communication of locks and changes' thread was
that it was "pointless" to cache impromptu locks since the client is
"always" out of date. (Impromptu locks are locks on files that do not
have 'svn:needs-lock', and/or other people's locks.)
In this case, 'svn:needs-lock' is there from the beginning (which is why
the readonly flag is set,) and that this is more of a reminder/warning
that one of your Applications changed your readonly file without your
knowledge. More importantly, 'svn:needs-lock' is already being cached
by the workspace, so all the lock information is already present.
All the information needed to determine if you should be touching that
file already exists, even when you're offline. The difference is that
it's telling you that you _definitely_ need to connect to the server and
lock the file, whereas the other thread was about caching inherently out
of date information about other people's locks.
A gui client could implement this on their own as a courtesy feature
without worrying about breaking standards (kind of like how Version
Trees are not standard.) For the command line folks, it would be more
convenient (and thus more like to be used) if 'svn status' would flag
any modified, no local lock, 'svn:needs-lock' file.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Get exclusive lock
Posted by Listman <li...@burble.net>.
On Mar 3, 2008, at 11:09 AM- Mar 3, 2008, Bicking, David (HHoldings,
IT) wrote:
> Yeah, so do I, but that's very similar to "communication of locks and
> changes" (because the fact that the file needs a lock has to be stored
> locally - though I suppose you could get that from the file
> properties),
> which was a long debate a few months back about "regular" locks.
> Client
> software teams such as Tortoise aren't interested in creating their
> own
> proprietary caching and communication mechanisms - they'd rather have
> the core software handle that. Caching lock status locally or
> regularly
> pinging the server for lock status is, according to the Subversion
> team,
> "right out".
it might make sense to cache your own locks i think.
> I feel that having client software automatically querying
> the server is a bad idea, anyway, because it increases network traffic
> and demand on the server.
depends on the environment, when you have *lots* of data and an svn
update
takes a while running a cron job to do this overnight isn't such a bad
idea..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Re: Get exclusive lock
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Reedick, Andrew [mailto:jr9445@ATT.COM]
> Sent: Monday, March 03, 2008 10:35 AM
> To: users@subversion.tigris.org
> Subject: RE: Re: Get exclusive lock
>
> > -----Original Message-----
> > From: Andy Levy [mailto:andy.levy@gmail.com]
> > Sent: Monday, March 03, 2008 7:12 AM
> > To: Oliver Fabelo
> > Cc: users@subversion.tigris.org
> > Subject: Re: Get exclusive lock
> >
> >
> > You're right - it's "an excuse". You can't use software to solve a
> > social or communication problem. Your colleagues need to take
> > responsibility for doing their job properly.
> >
> > How did they not "clobber" each others' work before SVN? It sounds
> > like you're doing everything you can form the SVN side with
> > svn:needs-lock.
> >
> > > The worst thing is that they are not mere users, are all
> computer's
> > degree
> >
> > Some of the most inept computer users I have met are
> programmers and
> > others responsible for keeping computer systems working. As above -
> > you aren't alone here.
> >
>
>
---------------- SNIP ------------------
>
>
> Persionally, multi-tasking, windowed OS clients like
> TortoiseSVN should have an option to periodically check for
> 'needs-lock' files that have been modified without a lock.
Yeah, so do I, but that's very similar to "communication of locks and
changes" (because the fact that the file needs a lock has to be stored
locally - though I suppose you could get that from the file properties),
which was a long debate a few months back about "regular" locks. Client
software teams such as Tortoise aren't interested in creating their own
proprietary caching and communication mechanisms - they'd rather have
the core software handle that. Caching lock status locally or regularly
pinging the server for lock status is, according to the Subversion team,
"right out". I feel that having client software automatically querying
the server is a bad idea, anyway, because it increases network traffic
and demand on the server.
--
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
RE: Re: Get exclusive lock
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Monday, March 03, 2008 7:12 AM
> To: Oliver Fabelo
> Cc: users@subversion.tigris.org
> Subject: Re: Get exclusive lock
>
>
> You're right - it's "an excuse". You can't use software to solve a
> social or communication problem. Your colleagues need to take
> responsibility for doing their job properly.
>
> How did they not "clobber" each others' work before SVN? It sounds
> like you're doing everything you can form the SVN side with
> svn:needs-lock.
>
> > The worst thing is that they are not mere users, are all computer's
> degree
>
> Some of the most inept computer users I have met are programmers and
> others responsible for keeping computer systems working. As above -
> you aren't alone here.
>
Yes, but you can use software to check for stupid states. If a file is
modified, has 'needs-lock' and lacks a lock, then the software should
flag it. Software is better at detecting such a condition than a human
is. Besides, a 'social or communication' solution would be for the
programmers of the OS, the Applications and the Version Control Software
to work together to protect 'needs-lock' files. Good luck on
implementing that social solution.
'needs-lock' is an important enough issue that the version control
system should be a bit more proactive about it. For example: instead of
relying on an OS level 'readonly' flag or running 'svn proplist -R', why
not add 'needs-lock' to 'svn status'? Any file that is modified with
'needs-lock' and no lock should be flagged as a conflict.
I think people run 'svn status' a lot more often than they run 'svn
proplist -R'. And custom clients are more likely to pay attention to
'svn status' than to properties.
Persionally, multi-tasking, windowed OS clients like TortoiseSVN should
have an option to periodically check for 'needs-lock' files that have
been modified without a lock.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Get exclusive lock
Posted by Andy Levy <an...@gmail.com>.
On Mon, Mar 3, 2008 at 7:01 AM, Oliver Fabelo
> We are in the same case, I am happy because someone understands me :-). I
> took days angry because the excuse of my colleagues is: "I can arrive at
> 8:00 half asleep and I can forget to lock the file ...".
You're right - it's "an excuse". You can't use software to solve a
social or communication problem. Your colleagues need to take
responsibility for doing their job properly.
How did they not "clobber" each others' work before SVN? It sounds
like you're doing everything you can form the SVN side with
svn:needs-lock.
> The worst thing is that they are not mere users, are all computer's degree
Some of the most inept computer users I have met are programmers and
others responsible for keeping computer systems working. As above -
you aren't alone here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Get exclusive lock
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Oliver Fabelo [mailto:ofabelo@canarias.org]
> Sent: Monday, March 03, 2008 7:01 AM
> To: users@subversion.tigris.org
> Subject: RE: Get exclusive lock
>
> Hello,
>
> We are in the same case, I am happy because someone understands me
:-).
> I
> took days angry because the excuse of my colleagues is: "I can arrive
> at
> 8:00 half asleep and I can forget to lock the file ...".
> The worst thing is that they are not mere users, are all computer's
> degree
> (my English is not very good, I'm sorry).
> Thanks beforehand.
>
The only version control system that I know of that can prevent the
problem would be a ClearCase dynamic view. The dynamic view intercepts
all OS file I/O calls thus preventing applications from ignoring the
'readonly' flag. However, ClearCase is expensive and dynamic views have
their own drawbacks.
Plan B: If your users put their checkouts under a particular directory,
you could install a script that will periodically scan the checkout dirs
and check if any svn:needs-lock files have been modified. 'svn proplist
-R ...'
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Get exclusive lock
Posted by Oliver Fabelo <of...@canarias.org>.
Hello,
-----Mensaje original-----
De: Andreas Schweigstill [mailto:andreas@schweigstill.de]
Enviado el: lunes, 03 de marzo de 2008 11:18
Para: users@subversion.tigris.org
Asunto: Re: Get exclusive lock
So it seems that you don't have a technical but psychological problem
to solve. I also noticed such pseudo-technical arguments just a few days
ago with one of a customer's employees. After resolving all of his
"technical problems" he just said: "OK, but I just won't use it at all
because I have never used it before." Btw. this was not related to
Subversion but to an internal Wiki which I set-up for the customer.
You have to be carefull that your colleagues won't pass the buck to you:
"All of our projects are delayed just because Oliver forced us to use
SVN instead of VSS. It's just his fault!"
-------------------
We are in the same case, I am happy because someone understands me :-). I
took days angry because the excuse of my colleagues is: "I can arrive at
8:00 half asleep and I can forget to lock the file ...".
The worst thing is that they are not mere users, are all computer's degree
(my English is not very good, I'm sorry).
Thanks beforehand.
Cheers...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Get exclusive lock
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Hello!
Oliver Fabelo schrieb:
> This is the
> only thing which my colleagues do not want to go svn ... (no comments).
So it seems that you don't have a technical but psychological problem
to solve. I also noticed such pseudo-technical arguments just a few days
ago with one of a customer's employees. After resolving all of his
"technical problems" he just said: "OK, but I just won't use it at all
because I have never used it before." Btw. this was not related to
Subversion but to an internal Wiki which I set-up for the customer.
You have to be carefull that your colleagues won't pass the buck to you:
"All of our projects are delayed just because Oliver forced us to use
SVN instead of VSS. It's just his fault!"
With best regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org