You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Kopp <da...@bellsouth.net> on 2003/11/03 04:10:11 UTC

lock:// protocol hacked in

Hello,

I have hacked in a lock protocol in my working copy. I added a
libsvn_ra_lock directory and implemented it as a new RA layer. I choose
to do this because I thought this functionality is a property of the
repository location, not of the repository itself.

I don't know a whole lot about patches and stuff, so I just ran svn diff
and redirected the output into a file.

Without further ado, here is lock.txt


David Kopp

Re: lock:// protocol hacked in

Posted by Branko Čibej <br...@xbc.nu>.
David Kopp wrote:

>Hello,
>
>I have hacked in a lock protocol in my working copy. I added a
>libsvn_ra_lock directory and implemented it as a new RA layer. I choose
>to do this because I thought this functionality is a property of the
>repository location, not of the repository itself.
>
>I don't know a whole lot about patches and stuff, so I just ran svn diff
>and redirected the output into a file.
>
>Without further ado, here is lock.txt
>  
>
If I understand your patch correctly, you have a nasty problem waiting
to happen. libsvn_ra_lock and libsvn_ra_local won't live in the same
shared libraries, yet you use non-public methods from ra_local in the
ra_lock implementation. That won't work.


-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: lock:// protocol hacked in

Posted by "C. Michael Pilato" <cm...@collab.net>.
David Kopp <da...@bellsouth.net> writes:

> I don't know a whole lot about patches and stuff, so I just ran svn diff
> and redirected the output into a file.

With the small exception of "... and you should also include a
properly formatted log message with all of your patches (see
HACKING)", you seem to know pretty much all you need to know about
patches and stuff.  Isn't it great when life is so simple?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: lock:// protocol hacked in

Posted by Files <fi...@poetryunlimited.com>.
Minor caveat - the comment in svn_ra_local__is_lock says it attempts the lock.

It does not. It just determines if a lock was requested and changes the URL to
a file:// if it is. Sorry. My mistake.

-- 
Shamim Islam
BA BS

Files said:
> David,
>
>> I have hacked in a lock protocol in my working copy. I added a
>> libsvn_ra_lock directory and implemented it as a new RA layer. I choose
>> to do this because I thought this functionality is a property of the
>> repository location, not of the repository itself.
>
> Would you consider something of the following sort? I notice yours is rather
> extensive and requires a lot of syncing of issues if ra_local changes even a
> little.
>
> It complies more directly with Greg Hudson's suggestion of piggybacking on
> ra_local.
>
> Just a suggestion.
>
> --
> Shamim Islam
> BA BS---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: lock:// protocol hacked in

Posted by Files <fi...@poetryunlimited.com>.
David,

> I have hacked in a lock protocol in my working copy. I added a
> libsvn_ra_lock directory and implemented it as a new RA layer. I choose
> to do this because I thought this functionality is a property of the
> repository location, not of the repository itself.

Would you consider something of the following sort? I notice yours is rather
extensive and requires a lot of syncing of issues if ra_local changes even a
little.

It complies more directly with Greg Hudson's suggestion of piggybacking on
ra_local.

Just a suggestion.

-- 
Shamim Islam
BA BS