AW: lock/unlock as an atomic operation

Hi Troy,

you are right when you say it is a communication aid. I do not want to see lock/unlock revisions.

What I would like to achieve is to not have some files unnessesarily locked. My application does need several binary files to operate. If one of the files cannot be locked it would be better that the lock operation would not be executed at all. When I cannot lock all the files means to me I cannot do anything with the other files where the lock operation succeeded.

In case one of my binary files could not be locked I have to unlock the files which could be locked.

This is the reason for my request to have an atomic lock/unlock.

Frank

-----Ursprüngliche Nachricht-----
Von: Troy Curtis Jr [mailto:troycurtisjr@gmail.com]
Gesendet: Freitag, 25. August 2006 02:33
An: Frank Rast
Cc: users@subversion.tigris.org
Betreff: Re: lock/unlock as an atomic operation

On 8/24/06, Frank Rast <rast@gefeg.com> wrote:
> Hello,
>
> I am having a problem with the lock/unlock feature.
>
> Almost every action in subversion is atomic eg. update, commit. When I add
> files they move to the repositry when I commit. When I change some
> properties of files it is reflected in the repository after a commit. If
> the commit fails, nothing in the repository changes. This is why I like
> subversion.
>
> When it comes to lock/unlock this principle does not apply. I can not
> schedule the files I want for locking and then commit this to the
> repository. It happens that I am able to lock one file but not the other
> wich I also need.
>
> I would like to use lock/unlock more like changing a property of files.
> This can be done in an atomic operation.
>
> Will it someday be possible to do atomic lock/unlock?
>
>
> Mit freundlichen Gruessen / Best regards
>
> Frank Rast
>
> =========================================
> GEFEG mbH
> Storkower Strasse 207
> D-10369 Berlin
> Tel.: +49 30 97 99 14 57
> Fax.: +49 30 97 99 14 22
> Mailto:rast@gefeg.com
> =========================================
>
>
>
>

You would not want the lock operation to be implemented as a property
because you wouldn't want to have hundreds of "Locked files for
editing" revisions laying around in your repo. Additionally, locks
are only a communication aid. If someone else is getting a lock to
one or more of the files you need before you do, then you need to talk
to them. Obviously you both have a need to edit that file and you
should probably cooridinate with them on the details of your
modifications. Especially if you are only using locks on binary
files which are difficult (if not impossible) to merge.

Troy

-- 
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)