Re: Revision Arithmetic

On Wed, 2005-08-31 at 12:09 +0100, Julian Foad wrote:
> Christopher Ness wrote:
> > I plan to do revision arithmetic, addition and subtraction of revision
> > numbers passed in as arguments as Karl said near Christmas 2004. Not
> > changes since this would overload the meaning of the -r flag.
>
> I'm not sure that this would overload the meaning of the -r flag any more than
> the existing ways to specifiy a revision by date or by keyword like "PREV" do.

Fair enough, but if I gave `svn log -r100-1` I would expect the log of
revision 99, not:
        {x | x >= 0 && x < 100 : x "is the next change set"}

> > 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 also stated in previous emails that I think the feature should be able
to work on keywords like HEAD (ie HEAD-2). Therefore the reg. ex. above
is wrong, but gets the basic point across.

> [...]
> > 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

I know you are looking at the common use case, but how can you force
people to use a feature in a narrow scope such as looking back one
revision (who says that revision has a change to it?)?

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.

> 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. 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.

> That's why (I thought) most people in the previous discussions and issue #1213
> decided that it would be more useful to compute a number of "changes" or
> "versions" of the particular item, rather than a number of revisions of the
> repository. I still feel it is probably only really useful to say "the
> previous version" and "the next version" of an item (and not N changes before
> or after).

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?"

Thoughts? Luckily I haven't started any of this so my personal costs of
changing direction or aborting are null.

Cheers,
Chris

-- 
PGP Public Key: http://www.nesser.org/pgp-key/
17:05:58 up 1:30, 2 users, load average: 0.45, 0.23, 0.20
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org