Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of bert@qqmail.nl designates
 74.125.82.48 as permitted sender)
From: "Bert Huijben" <bert@qqmail.nl>
To: =?utf-8?Q?'Branko_=C4=8Cibej'?= <brane@wandisco.com>,
	"'Subversion Development'" <dev@subversion.apache.org>
References: <54579C00.8090304@wandisco.com> <54B8E2B8.3070606@wandisco.com>
 <54DC7C9C.2010508@wandisco.com> <54E155F4.1090202@wandisco.com>
In-Reply-To: <54E155F4.1090202@wandisco.com>
Subject: RE: Time to branch 1.9
Date: Mon, 16 Feb 2015 10:01:18 +0100
Message-ID: <02b801d049c7$2131b650$639522f0$@qqmail.nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH9CQfMbMvAPXXuVr7C2NBu3/itygF5196IAghSI50CYwYtrJxqUD6g
Content-Language: nl


> -----Original Message-----
> From: Branko =C4=8Cibej [mailto:brane@wandisco.com]
> Sent: maandag 16 februari 2015 03:29
> To: Subversion Development
> Subject: Re: Time to branch 1.9
>=20
> On 12.02.2015 11:12, Branko =C4=8Cibej wrote:
> > On 16.01.2015 11:06, Branko =C4=8Cibej 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
>=20
> I decided not to create the branch yet, as we have a number of (actual
> and potential) release blockers.
>=20
> These are the issues tagged with the 1.9.0 milestone:
> http://s.apache.org/cQw
>=20
>   * 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.
>=20
>   * 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.
>=20
>   * 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.
>=20
>   * 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@BASE + svn =
cat x@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


>=20
>=20
> 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.
>=20
> -- Brane