David Glasser wrote:
> 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.
It's not that some of these commands are susceptible to race conditions and
others are not: they all are. It's just a question of degree and likelihood.
Example:
[[[
INITIALLY
svn:ignore = *.tmp
USER1
# Temporary files don't need to be ignored any more:
svn propdel svn:ignore
USER2
# Adds "*.bak":
svn propset svn:ignore "*.tmp
*.bak"
RESULT
Same race condition as if USER1 had been using "propset".
]]]
This not-unlikely scenario shows that "propdel" is not unlike "propset" in its
ability to participate in race conditions, only more limited in the variety of
changes it can make.
Also consider that often the user will be pretty certain that the path
specified is not being changed by other people in any way that matters. E.g.
"svn propset p v /branches/julian1": it's my branch so I'm pretty sure no-one
else is touching it. I don't want to be forced to specify the revision number
when I don't have any practical need to do so.
Anyway, forcing the user to specify a peg revision doesn't force the user to
note and specify the correct revision. He can just specify "HEAD", or, if we
disallow that, any recent revision number.
So please let's keep the syntax consistent across all commands.
- Julian
---------------------------------------------------------------------
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 21:42:13 CET