subclipse 1.7: why is it then now merge->block revision seems to need to download the whole revision?

[jcompagner]

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

johan

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2822061

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[Mark Phippard]

Post by jcompagner
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:

http://subversion.apache.org/docs/release-notes/1.7.html#merge-tracking-enhancements

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:

http://svn.haxx.se/dev/archive-2009-09/0520.shtml
--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2822064

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[jcompagner]

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
another branch)
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
it!!
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!

johan

Post by Mark Phippard

Post by jcompagner
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.
http://subversion.apache.org/docs/release-notes/1.7.html#merge-tracking-enhancements
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
http://svn.haxx.se/dev/archive-2009-09/0520.shtml
--
Thanks
Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2822065

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].

[Mark Phippard]

Thanks. I will at least point the devs at this thread. The current
behavior is not ideal. I would be nice if there were at least some kind of
additional option to just sy\ay "record this revision" do not contact the
server, I do not need the other stuff done.

Post by jcompagner
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
another branch)
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
it!!
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!
johan

Post by Mark Phippard

Post by jcompagner
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

Post by Mark Phippard
about it regardless.

http://subversion.apache.org/docs/release-notes/1.7.html#merge-tracking-enhancements

Post by Mark Phippard
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

Post by Mark Phippard
http://svn.haxx.se/dev/archive-2009-09/0520.shtml
--
Thanks
Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2822065
To unsubscribe from this discussion, e-mail: [

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=2822071

To unsubscribe from this discussion, e-mail: [dev-***@subclipse.tigris.org].