> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: maandag 16 februari 2015 03:29
> To: Subversion Development
> Subject: Re: Time to branch 1.9
>
> On 12.02.2015 11:12, Branko Čibej wrote:
> > On 16.01.2015 11:06, Branko Čibej wrote:
> >> A couple months down the line, and I'd like to make another call for
> >> creating the 1.9 release branch. AFAICS the x509 branch still needs
> >> merging if we want it in 1.9 (which I think we do, since IIUC trunk
> >> currently does not handle all certs correctly).
> >>
> >> Anything else?
> >>
> >> I'd like to propose that we cut the branch and roll an RC (or a beta) in
> >> a couple weeks.
> >
> > Looks like we're on track for branching around the beginning of next week.
> >
> > * the x509 branch is on trunk;
> > * the heisenbug (actually, several heisenbugs) in ra-test seem to have
> > been fixed;
> > * Stefan^1 's pin-externals branch has been lazy-consensus'd for merge
> > to trunk (some changes still pending, but those don't have to happen
> > on the branch);
> > * The problem with Python bindings and Swig 3.0.x is, for now, assumed
> > to be a bug in Swig itself; I propose we disable support for Swig-3
> > for now (Swig-2 still works fine);
> > * Ivan and I agreed not to propose to merge the reuse-ra-session
> > branch in time for 1.9, we can merge it after the soak period an let
> > it marinate a bit on trunk for 1.10;
> > * Bert appears to be mostly finished with his (fantastic!) fixes for
> > working copy move handling and conflict resolution;
> > * buildbots are green.
> >
> > If there are no further objections, and the pin-externals branch gets
> > merged soon-ish, I intend to create the 1.9 release branch on Sunday
> > night or Monday early morning (UTC). Ben has kindly been volunteered to
> > RM the first 1.9 release candidate
>
> I decided not to create the branch yet, as we have a number of (actual
> and potential) release blockers.
>
> These are the issues tagged with the 1.9.0 milestone:
> http://s.apache.org/cQw
>
> * 4502 Remove FSFS7 disk format changes
> We've had this discussion several times. AIUI Ivan still believes we
> should remove log addressing, even though all of the points he
> raised have been addressed. I propose we close this issue.
>
> * 4556 Replace 'svn youngest' with another UI
> Not much discussion here. I propose we do either option 2 ('svnmucc
> youngest'), or rip out the subcommand entirely since there are lots
> of ways to the info.
>
> * 4558, 4559, 4560: These are all about pin-externals. They shouldn't
> take too long to fix; basically, the pin-externals feature needs a
> lot more tests to catch the trivial errors sooner.
>
> * 4500 API: describe four-way conflicts losslessly
> I don't know what to do about this. Bert, you recently made a slew
> of changes in the conflict resolver; your opinion would be valuable
> here.
I don't think issue 4500 should delay 1.9.0.
This is about representing tree conflicts on merges where there are 4 interesting revisions.
On a merge we merge the difference between URL1 and URL2 into a working copy which was original from URL3, but can have local changes.
The problem described here is that we don't describe URL3 in the merge-info skel. Personally I don't think we should ever describe this in the skel, as we already have all that information in NODES. Duplicating the information requires keeping it synchronized...
I think it is better to obtain that information (if we need it) directly from BASE. (A simple svn info X + svn cat X (or svn info X_at_BASE + svn cat x_at_BASE on deletes) provides all of the info we have for the other URLs and even a bitmore
On Update/Switch URL1 and URL3 are the same thing, so in that case we do store the information.
Duplicating the information will require some form of working copy format bump as the conflict skels will no longer be backwards compatible with 1.8.
Note that for the property conflicts described in the conflict the 4 way information is already implemented: It just fetches the nodes from the PRISTINE layer in NODES.
(It used to fetch them from BASE, but I recently fixed that... as op-depth 0 doesn't have to exist; especially during merges)
Bert
>
>
> These are defects tagged 1.9.0-consider: http://s.apache.org/Nft
> I'd appreciate getting some help with these; some are probably already
> fixed, a few may be release blockers.
>
> -- Brane
Received on 2015-02-16 10:01:52 CET