[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Checkins without prior checkout avoiding WC?

From: Max Bowsher <maxb_at_ukf.net>
Date: 2004-08-20 14:45:15 CEST

Peter Valdemar Mørch wrote:
> Is it even possible? I can import, cp, mv, and rm without a WC, but not
> ci, it seems. If it isn't possible, is that because of an implementation
> or policy decision?
>
> Also, /trunk/notes/locking-design.txt contains:
>> 'svn lock' returns a lock-token to the client, then stored in the WC.
>
> Could I humbly request that "locking" and "unlocking", when available,
> also become possible without a WC?
>
> Before anyone screems "You want to do *WHAT*?" - please bear with me:
>
> I'm not really against a WC, it just doesn't buy me anything in the case
> of the read/write web-client I'm adding to WebSVN, because the svn
> client and the WC are located on the web server, and not at the
> end-user, the web-client.

You should take a look at the svn_ra API. Whilst it is very WC oriented, at
no point does it assume anything about the format - so your WC could be a
set of data structures in memory - or shipped to and from the client in a
cookie.

> One of the purposes of the WC is to detect conflicts, but since the
> editing is done on the *web* client and then the document is
> resubmitted, we have no idea what version the user really started with

We are talking about a web form here? Then why not just send the revision
number that the user began editing in a hidden form field, and check for
conflicts on submission? If no conflict, commit, if conflict, do a merge,
and feed the result back to the user with conflict markers embedded for
further editing.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 20 14:45:56 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.