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

Re: Suggestion: "svn explain"

From: <cmpilato_at_collab.net>
Date: 2002-08-04 17:54:58 CEST

Garrett Rooney <rooneg@electricjellyfish.net> writes:

> On Sun, Aug 04, 2002 at 11:11:17AM +1000, Martin Pool wrote:
> > On 3 Aug 2002, Gareth McCaughan <Gareth.McCaughan@pobox.com> wrote:
> > > On Saturday 03 August 2002 3:22 pm, Martin Pool wrote:
> >
> > > 1. I see nothing that guarantees that the error IDs will never
> > > change. They're allocated sequentially-by-magic in
> > > svn_error_codes.h, and if someone ever adds a new one
> > > then all the later errors will get their IDs bumped up. Since
> > > they are (currently) arranged in groups, it seems quite
> > > likely that errors will get added in the middle of the list.
> >
> > I think if Subversion exposes error codes in messages, people will
> > count on them to be the same. Changing them would be confusing.
> i believe there has been an issue filed about just this problem,
> although i don't know what the plan is to deal with it. perhaps
> allocating extra error values at various points in the sequence for
> later expansion, like one can do with space in data structures when
> trying to maintain binary compatability...

That is precisely the plan. We need to group our error codes into
those that can be sent across the wire, and those that can't, leaving
empty error slots between the groups. And then, from 1.0 on out, we
implement an error code policy that is consistent with our API policy
and that dictates how we choose version numbers for our product such
that compatibility between versions can be easily predicted and
explained. Greg Stein has, somewhere (perhaps in the APR tree) a plan
for just such a version-number-choosing scheme.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 4 17:55:32 2002

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.