Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 26 Oct 2011 12:28:32 +0200
From: Stefan Sperling <stsp@elego.de>
To: James French <James.French@naturalmotion.com>
Cc: "users@subversion.apache.org" <users@subversion.apache.org>
Subject: Re: Behaviour of reintegrate in 1.7.1
Message-ID: <20111026102832.GD10387@ted.stsp.name>
Mail-Followup-To: James French <James.French@naturalmotion.com>,
	"users@subversion.apache.org" <users@subversion.apache.org>
References: <950618E0D00138499BE7CC487EBF646D66FF58D19C@WOODCHUCK.NM.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <950618E0D00138499BE7CC487EBF646D66FF58D19C@WOODCHUCK.NM.local>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Wed, Oct 26, 2011 at 10:02:17AM +0100, James French wrote:
> I was prompted to give 1.7.1 a shot when a reintegrate merge task
> turned up where the destination checkout was sparse, which was not
> possible at all in 1.6. If memory serves me correctly with 1.6 you
> could reintegrate into you working copy provided that the development
> branch had been fully synced up to the same revision as the working
> copy.

This is correct.

> Once the reintegration was complete you could update to merge in
> any further checkins and then checkin yourself.

Not sure what you mean here, this is very unclear.
Update which working copy?
Merge further revisions from which branch to where?

>Am I correct in this?

See
http://mail-archives.apache.org/mod_mbox/subversion-dev/201107.mbox/%3C20110720124721.GA7557@ted.stsp.name%3E
for a more precise explanation.

> With 1.7.1 (tortoisesvn), it seemed that this might not be the case.
> The dev branch was synced up to revision 10769 and the destination
> working copy was alsio at 10769 (using update to revision). When I
> tried to reintegrate svn complained that revisions beyond the revision
> of the working copy had not been synced up, and as other people
> checked in this number appeared to grow.

No idea. Can you please show the exact error message you got?

>From where I stand it sounds as if you simply haven't closed all gaps
in the revision ranges already synced from trunk to the branch.

But maybe this is a separate problem related to the sparse working copy?
Can you show us how to reproduce the problem starting from an empty
test repository?

> I did not look much further than this, but this seemed fishy so I
> thought I'd ask here. We're used to loads of hassle with mergeinfo and
> reintegrate merges (this is one area I'm praying that svn 1.7 will
> greatly improve). The merge info has been such a headache over the
> last few years that we're all a bit confused as to what's correct,
> what's buggy, what's left over from previous bugs...

I hope that 1.7 will improve things for you.
Note that benefits are most visible with branches created and
maintained exclusively with 1.7 clients.