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

Re: Revision Arithmetic

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-09-04 00:38:54 CEST

Christopher, you might want to skip to the very end of this message before
reading my boring point-by-point responses.

Christopher Ness wrote:
> On Wed, 2005-08-31 at 12:09 +0100, Julian Foad wrote:
>>Christopher Ness wrote:
>>
>>>I plan to extend the argument parsing to look for something like:
>>> ([0-9][0-9+-]*)*[0-9]+
>>>where the revision argument must start and end with a number and can
>>>have addition or subtraction chars but not as the first or last char.
>>
>>Seems far too loose.
>
> Could you be a little more verbose?

I meant that that allows multiple operators in a group which doesn't make
sense, and multiple terms in the expression which seems overkill, e.g.
"000-+-101-+-000". I think "number, possibly plus or minus another number"
([0-9]+([+-][0-9]+)?) would be more than adequate.

[...]
>>>I have designed this to allow: -r1000-1
>>> and disallow: -r-1+1000
>>>
>>>Is this acceptable? I would think the common use case would be N-x for
>>>a previous revision.
>>
>>No, I wouldn't accept this.
>>
>>"N-1" is the only thing I can see being useful.
>
> HEAD = r100
> svn co -r66 $REPOS
> svn diff -r66+5:HEAD-10

Is that supposed to be an example of something useful? Why? In what possible
realistic scenario would you know that something interesting happened five
revisions after the one you checked out or ten revisions before the current head?

There's no point in providing the ability to do arithmetic if it gives no real
benefit.

[...]
> I couldn't begin to tell you how people may use this feature. I'm sure
> some will abuse it, but that often leads to innovations.

Well, we can't add a feature just because it's possible, without any idea of
how it will be used constructively.

>>It gives the previous version
>>of an item iff N is a revision in which the item changed, which is a reasonably
>>common usage. In most projects, revision "N+1" of a particular tree or item is
>>often the same tree as revision "N" of it (because something elsewhere in the
>>repository has changed), and similarly "N-2" the same as "N-1". If you think
>>there is any use for adding a number, or subtracting any number other than one,
>>please give a realistic use case.
>
> I don't think you can make these generalizations.

Heh. I think I can. :-)

> The idea isn't to
> think about change sets but to save the user from having to do
> arithmetic in their heads (possibly incorrectly). Just do it in the
> argument and let the program calculate it for you.

Again, I say, "In what circumstances does a user want to do such arithmetic?"
The only good, common example I can think of is wanting to see the change that
resulted in revision N; for this case, the revision in which the item was
changed before rN is wanted, or just N-1 will do the job too.

> I am not suggesting to implement "N changes", but simply arithmetic for
> revisions which is easily understood by the vast majority of users
> (except for maybe those who know how things work under the hood).
>
> I guess the question comes down to:
> "Is basic revision arithmetic something subversion should have?"

No, it isn't. Sorry :-(

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 4 00:39:41 2005

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.