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

Re: working copy format bump on trunk this week?

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 19 Sep 2012 16:43:39 +0200

On Wed, Sep 19, 2012 at 06:36:04AM -0700, C. Michael Pilato wrote:
> On 09/19/2012 02:33 AM, Stefan Sperling wrote:
> > No responses so far. Does that mean there are no objections?
>
> The US/Europe CollabNet committers are all traveling this week for meetings,
> so expect a slower response rate from us.

Fine. BTW, I just talked to Bert on IRC, he's fine with me bumping
the format as proposed, tonight CEST.

> Paul's 'inheritable-props' branch work expects to make changes in format 30,
> too, and that work has not (as far as I know) been merged to trunk. I think
> it would be a shame to "go live" with format 30 today and then force Paul to
> introduce a format 31 when he later merges his branch (which is, IMO, almost
> ready for reintegration).

I tried to address this point in my original mail, but allow me
to elaborate:

I know Paul has already bumped to 30 on his branch.
This now means that either everyone else is blocked from bumping
and has to wait, or that Paul will have to perform another bump
after merging from trunk (and perhaps deal with the fallout of having
working copies labeled '30' that now aren't the official trunk '30').

If Paul is travelling this week and thus won't get to integrating
his branch this week, then why should I have to wait in order to
start comitting code on trunk that is based on Bert's new conflict
storage? :) Cause right now I'm already hacking in a local working
copy with a patched client that is already over the bump (with a
format 30 that's different to Paul's! -- I guess that's collective
poor planning on our part...)

I could of course go on a branch, too, and perform a local bump there.
However that doesn't solve the problem that we'll have to bump anyway
at some point, and that we'll have to agree on the feature set of
format 30. And I might not have much time for this next week.

It would of course be best to integrate this all in one go.
However, I don't think we should be afraid of format bumps to the
point where people are waiting for each other for several days
to make progress.

I don't want to force this down anyone's throat though. I can deal
with this locally as well, and wait for Paul's changes to be merged
to trunk. However, if Paul's merge is to be a clean one, then *his*
format 30 will be used, and I'll have to make my changes in 31.

> Oh. I also still abhor the fact that we auto-upgrade working copies. But I
> suppose that's a different rant for a different thread/sympathic_audience.

Agreed and agreed. It also makes development harder in situations
like these, since it forces people with different format '30' working
copies to remember which client they used on it... :(
Received on 2012-09-19 16:44:21 CEST

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.