ahh ok then that's what i am seeing now.
A bit annoying because many times when i do block version it is
because that was a big binary dump (an eclipse target or plugins that
we compile against) on a branch that i don't need on trunk. (or
But i was correct in seeing that it now takes way more time to do it
with those kind of commits.
I can live with it, (just need to be sure that i am at home or at a
place with a fast Internet connection :) )
The other new feature "Reduced subtree mergeinfo changes" is paying
back the lost time big time..
I still have a few co workers that sometimes do merge on file only,
instead of root. Even after i told them quite a few times how to do
so how many times i also have deleted the svn:merge property on
specific files or dirs.... and committed that with a merge from my
self, i lost count..
But i guess that should be all over now!
On Tue, Aug 16, 2011 at 16:07, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, Aug 16, 2011 at 9:57 AM, jcompagner <jcompagner_at_gmail.com> wrote:
>> Was that also in 1.6? I can't remember that
>> But now if i do block revision of a quite a large commit it has to
>> download many megabytes of that commit first.
>> Why is that? Can't it just add that revision it to the properties??
>> Because thats the only thing it is really changed
> I assume you know it is the Subversion code doing this, so nothing we can do
> about it regardless.
> There were changes in --record-only merges made in 1.7:
> I believe that --record-only used to only record the revision you were
> recording. Now it also looks if that revision did any merges and also
> applies the mergeinfo from that revision. So that must be the traffic you
> are seeing. See:
> Mark Phippard
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2011-08-16 16:16:52 CEST