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

Re: [PATCH] Add URL support for propset and propdel and fix URL support for propedit

From: David Glasser <glasser_at_davidglasser.net>
Date: Thu, 28 Feb 2008 11:02:57 -0800

On Thu, Feb 28, 2008 at 10:40 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
>
> David Glasser wrote:
> > On Thu, Feb 28, 2008 at 9:17 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> >
> >>David Glasser wrote:
> >>
> >>
> >>>Julian Foad wrote:
> >>
> >> >> Therefore I'd propose just adding [@PEGREV] support to the target URL in all
> >> >> commands that are to support this feature:
> >> >>
> >> >> svn pdel URL[@PEGREV]
> >> >> svn pset URL[@PEGREV]
> >> >> svn pedit URL[@PEGREV]
> >> >> svn copy SRC[@PEGREV]... DSTURL[@PEGREV]
> >> >> ...
> >> >>
> >> >> Notice that "pedit" reads and writes a single object, and the notion of both
> >> >> reading from "URL_at_PEG" and writing a new revision based on the same "URL_at_PEG"
> >> >> makes total sense.
> >> >>
> >> >> I'm still willing to hear any counter-proposals. The main ones I can think of are:
> >> >>
> >> >> [--base-rev=BASEREV] URL[@PEGREV]
> >> >> (as I sketched above, where BASEREV and PEGREV are usually the same, and
> >> >> BASEREV should not be specified without PEGREV because it would be ambiguous)
> >> >>
> >> >> [--base-rev=BASEREV] URL
> >> >> (where BASEREV defaults to HEAD and is used both as the Base Revision and
> >> >> as the Peg Revision for URL, instead of "@" syntax)
> >> >>
> >> >> (And "--base-rev" would probably need a better name.)
> >> >>
> >> >> Can anyone see a strong reason for or against any of these?
> >> >
> >> > I think your proposal is good, but for the specific case of "propset"
> >> > I think the pegrev should be *required*.
> >>
> >> Why, specifically?
> >
> > Um, for the same reason that we historically haven't supported propset
> > on URLs --- so you don't clobber somebody else's changes in the
> > meantime? (Would you support letting "svn import" (with no special
> > "--replace"/"--force"/etc flags or baserev-type argument) overwriting
> > file contents by default?
>
> It's not the case that only "propset" could clobber other people's changes. So
> can "svn rm URL" and "svn mv URL URL" already, and propdel, import, merge, etc.
> also could if we were to allow them to. So that's not the sole reason we
> haven't supported propset on URLs.
>
> I don't see anything special about "propset" compared to the other commands.
>
> - Julian

I do think there's a difference between "erase this" and "change this
to that". Consider something like svn:ignore or svn:externals, for
example. One could assume for "erase svn:ignore", the user wouldn't
care what the previous value is; but for "add a line" or "change this
particular line" or "delete a line", the race condition is nastier.

That is, anywhere where a "merge" (not in the 'svn merge' sense, but
in the textual sense) is necessary shouldn't allow the race condition.
 "rm" and "mv" are different here. And you say "import" and "merge"
could, but I would be opposed to that as well!

If people really want to make themselves suspectable to race
conditions, our API allows it, and they can use svnput or the like.
But let's not put it in the default client.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-28 20:03:37 CET

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

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