You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pb...@collab.net> on 2007/12/03 20:26:04 UTC
How much deference to early adopters? Was: [RFC] QA of manually set svn:mergeinfo
In r28213, I put some restrictions in place as to what values svn ps
svn:mergeinfo will permit (previously we allowed just about anything).
Most of these restrictions were already checked for in
svn_mergeinfo_parse(), except for one: mergeinfo with paths that map to
empty revisions. As
http://subversion.tigris.org/issues/show_bug.cgi?id=3029* discusses
these are redundant and best avoided. With r28213 The checks are done
by leveraging svn_mergeinfo_parse() and then performing a second check
for empty ranges.
I'd like to move the empty range check into svn_mergeinfo_parse(), but I
worry about users who have been working with trunk builds the last year
and have mergeinfo in their repositories with paths mapped to empty
ranges. Since svn_mergeinfo_parse() would error out when trying even
list their svn:mergeinfo it would be pretty hard for them to fix. *So
now for my real question*: How much deference should we give to those
users who have been using trunk builds?
Paul
* Yes, yes, I know as we battle with issue #2897 and all the "Big" (tm)
questions, that the small details like this don't get much attention,
but a fantastic new A-class office building with the three L's ain't
much if the toilets don't work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: How much deference to early adopters? Was: [RFC] QA of manually set svn:mergeinfo
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: Daniel Rall [mailto:dlr@finemaltcoding.com]
> Sent: Monday, December 03, 2007 4:39 PM
> To: Paul Burba
> Cc: dev@subversion.tigris.org
> Subject: Re: How much deference to early adopters? Was: [RFC]
> QA of manually set svn:mergeinfo
<snip>
> > *So now for my real question*: How much deference should we give to
> > those users who have been using trunk builds?
>
> We make no compatibility guarantee on unreleased software.
> If there had been an RC of 1.5, this might be a different
> story, but there hasn't; so at this point, let's DTRT for the
> software.
>
> > * Yes, yes, I know as we battle with issue #2897 and all the "Big"
> > (tm) questions, that the small details like this don't get much
> > attention, but a fantastic new A-class office building with
> the three
> > L's ain't much if the toilets don't work.
>
> We know for certain that the entire schema is going to change
> to properly support reflected revisions (issue #2897). So, a
> database and/or FS-level migration is already going to be
> necessary for early adopters.
I moved the check for paths mapped to empty revision ranges to
svn_mergeinfo_parse() in r28235. That should put issue #3029 to bed for
good.
>
> Daniel Rall
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: How much deference to early adopters? Was: [RFC] QA of manually set svn:mergeinfo
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Mon, 03 Dec 2007, Paul Burba wrote:
> In r28213, I put some restrictions in place as to what values svn ps
> svn:mergeinfo will permit (previously we allowed just about anything).
> Most of these restrictions were already checked for in
> svn_mergeinfo_parse(), except for one: mergeinfo with paths that map to
> empty revisions. As
> http://subversion.tigris.org/issues/show_bug.cgi?id=3029* discusses
> these are redundant and best avoided. With r28213 The checks are done
> by leveraging svn_mergeinfo_parse() and then performing a second check
> for empty ranges.
>
> I'd like to move the empty range check into svn_mergeinfo_parse(), but I
> worry about users who have been working with trunk builds the last year
> and have mergeinfo in their repositories with paths mapped to empty
> ranges. Since svn_mergeinfo_parse() would error out when trying even
> list their svn:mergeinfo it would be pretty hard for them to fix. *So
> now for my real question*: How much deference should we give to those
> users who have been using trunk builds?
We make no compatibility guarantee on unreleased software. If there had
been an RC of 1.5, this might be a different story, but there hasn't; so
at this point, let's DTRT for the software.
> * Yes, yes, I know as we battle with issue #2897 and all the "Big" (tm)
> questions, that the small details like this don't get much attention,
> but a fantastic new A-class office building with the three L's ain't
> much if the toilets don't work.
We know for certain that the entire schema is going to change to properly
support reflected revisions (issue #2897). So, a database and/or FS-level
migration is already going to be necessary for early adopters.
--
Daniel Rall
Re: How much deference to early adopters? Was: [RFC] QA of manually set svn:mergeinfo
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Dec 3, 2007 12:34 PM, David Glasser <gl...@davidglasser.net> wrote:
> It's important to give notification when incompatible changes hit
> trunk (we could even do this in a file or issue or something instead
> of relying on constant mailing list reading), and if it's easy enough
> posting a migration script might help. But we shouldn't leave code in
> the actual codebase to migrate from unreleased versions.
FreeBSD ports has an UPDATING file - perhaps we should have a similar
file in trunk (REPOS_UPDATING?) documenting all repos changes ordered
by date? Tho, I'm not sure how often that'll be used if it's worth
the hassle... *shrug* -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: How much deference to early adopters? Was: [RFC] QA of manually set svn:mergeinfo
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 3, 2007 12:26 PM, Paul Burba <pb...@collab.net> wrote:
> In r28213, I put some restrictions in place as to what values svn ps
> svn:mergeinfo will permit (previously we allowed just about anything).
> Most of these restrictions were already checked for in
> svn_mergeinfo_parse(), except for one: mergeinfo with paths that map to
> empty revisions. As
> http://subversion.tigris.org/issues/show_bug.cgi?id=3029* discusses
> these are redundant and best avoided. With r28213 The checks are done
> by leveraging svn_mergeinfo_parse() and then performing a second check
> for empty ranges.
>
> I'd like to move the empty range check into svn_mergeinfo_parse(), but I
> worry about users who have been working with trunk builds the last year
> and have mergeinfo in their repositories with paths mapped to empty
> ranges. Since svn_mergeinfo_parse() would error out when trying even
> list their svn:mergeinfo it would be pretty hard for them to fix. *So
> now for my real question*: How much deference should we give to those
> users who have been using trunk builds?
>
> Paul
>
> * Yes, yes, I know as we battle with issue #2897 and all the "Big" (tm)
> questions, that the small details like this don't get much attention,
> but a fantastic new A-class office building with the three L's ain't
> much if the toilets don't work.
It's important to give notification when incompatible changes hit
trunk (we could even do this in a file or issue or something instead
of relying on constant mailing list reading), and if it's easy enough
posting a migration script might help. But we shouldn't leave code in
the actual codebase to migrate from unreleased versions.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org