svn relocate on 1.7.0-rc4 doesn't work on subdirectories anymore?
Hi, On subversion 1.6 I am able to: svn sw -relocate FROM_URL TO_URL WC/subdir When I try this on 1.7.0-rc4 I get an error E155019: svn: E155019: Cannot relocate 'WC/subdir' as it is not the root of a working copy; try relocating 'WC' instead. I noticed that the "-relocate" option has been deprecated by "svn relocate" and from the documentation it changes the url of "the working copy". Is there a plan to support relocating subdirectories or is this feature "gone"? Thanks for any help! Christian Asmussen Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases.
RE: svn relocate on 1.7.0-rc4 doesn't work on subdirectories anymore?
Our source tree is quite big (2G), and we provide svn:// access for RO and https:// access for RW using a SSO solution for authorization. Our scripts allow our users to perform a sparse checkout, and when they need to actually checkout something big, basically this is what we used to do. svn up --set-depth empty WC/bigSubDir svn sw --relocate RW_URL RO_URL WC/bigSubDir svn up --set-depth infinity WC/bigSubDir svn sw --relocate RO_URL RW_URL WC/bigSubDir This would speed up the big update (infinity) by about 60% in our case. The reason why we did it this way (relocating the subdir) is because in case the user had another big subdirectory checked out with infinity, the first svn switch would take so long that it was no longer worth it. I've been testing this with 1.7-rc4 and this is no longer the case, meaning the "svn relocate URL" seems to take constant time, independent of the size and amount of WC/subdir(s) you have. I guess that is expected with WC-NG since it only has to change metadata in one place. More and more this seems to be a non-issue for on my case. Regards Christian Asmussen -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: 10 October 2011 15:32 To: Asmussen, Christian; users@subversion.apache.org Subject: RE: svn relocate on 1.7.0-rc4 doesn't work on subdirectories anymore? > Hi, > On subversion 1.6 I am able to: > svn sw -relocate FROM_URL TO_URL WC/subdir > > When I try this on 1.7.0-rc4 I get an error E155019: > svn: E155019: Cannot relocate 'WC/subdir' as it is not the root > of a working copy; try relocating 'WC' instead. > > I noticed that the "-relocate" option has been deprecated by "svn relocate" > and from the documentation it changes the url of "the working copy". > > Is there a plan to support relocating subdirectories or is this feature "gone"? > > Thanks for any help! > Christian Asmussen > I'm curious what's the use case here. Relocate is used when you move a repository to a new location (URL). So, you moved your server but don't want to point the full working directory to the new server location? BOb Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases.
SVN 1.7 svn up --set-depth exclude DIR takes very long
I checkout a big subdirectory (more than 1giga), then I want to get rid of it locally, so I do svn up -set-depth exclude DIR It takes very long... If I strace the process, it's doing read/lseek repeatedly read(3, "\2\0\0\0\2\2\275\0\0\2\253\34\2\275\3g\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" ..., 1024) = 1024 lseek(3, 179087360, SEEK_SET) = 179087360 read(3, "\n\0\0\0\4\1v\0\1v\2\33\2\265\3T\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 lseek(3, 179083264, SEEK_SET) = 179083264 read(3, "\n\0\0\0\2\2\255\0\2\255\3V\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"... , 1024) = 1024 lseek(3, 179072000, SEEK_SET) = 179072000 read(3, "\n\0\0\0\3\0020\0\0020\2\311\3_\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"... , 1024) = 1024 lseek(3, 179121152, SEEK_SET) = 179121152 read(3, "\2\0\0\0\3\2F\0\0\2\252\231\2F\2\335\3o\0\0\0\0\0\0\0\0\0\0\0\0\0\0"... , 1024) = 1024 lseek(3, 178926592, SEEK_SET) = 178926592 read(3, "\n\0\0\0\4\1\220\0\1\220\2#\2\276\3]\3\21\3[\3\262\0\0\0\0\0\0\0\0\0\0" ..., 1024) = 1024 lseek(3, 178630656, SEEK_SET) = 178630656 Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases.
Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links
Dear "Users",
It seems that on svn 1.7.1 deleted symbolic links on a branch cause a
tree conflict when a -reintegrate merge is done back to trunk.
The same merge done with svn 1.6.17 smoothly passes as a normal
deletion.
See below a simple "script" to replicate the bug:
# svn, version 1.7.1 (r1186859)
REPO=${HOME}/TestRepo
svnadmin create $REPO
svn mkdir -m "init" file://$REPO/trunk file://$REPO/branches
svn co file://$REPO wc
touch wc/trunk/file
ln -s file wc/trunk/link
svn add wc/trunk/file wc/trunk/link
svn ci -m "link" wc
svn cp -m "branch 1.0" file://$REPO/trunk file://$REPO/branches/1.0
svn up wc
svn rm wc/branches/1.0/link
svn ci -m "rm link" wc
svn merge --reintegrate ^/branches/1.0 wc/trunk
--- Merging differences between repository URLs into 'wc/trunk':
C wc/trunk/link
--- Recording mergeinfo for merge between repository URLs into
'wc/trunk':
U wc/trunk
Summary of conflicts:
Tree conflicts: 1
The same when executed with svn, version 1.6.17 (r1128011)
#Only the last command differs
svn merge --reintegrate ^/branches/1.0 wc/trunk
--- Merging differences between repository URLs into 'wc/trunk':
Dwc/trunk/link
Is this really a bug? Or am I doing something wrong?
Regards
Christian Asmussen
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
RE: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links
Issue created http://subversion.tigris.org/issues/show_bug.cgi?id=4052
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: 09 November 2011 17:57
To: Asmussen, Christian
Cc: users@subversion.apache.org
Subject: Re: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic
links
On Wed, Nov 09, 2011 at 04:13:56PM +0100, christian.asmus...@ubs.com
wrote:
> Dear "Users",
>
>
>
> It seems that on svn 1.7.1 deleted symbolic links on a branch cause a
> tree conflict when a -reintegrate merge is done back to trunk.
>
> The same merge done with svn 1.6.17 smoothly passes as a normal
> deletion.
>
>
>
> See below a simple "script" to replicate the bug:
>
>
>
> # svn, version 1.7.1 (r1186859)
>
> REPO=${HOME}/TestRepo
>
> svnadmin create $REPO
>
> svn mkdir -m "init" file://$REPO/trunk file://$REPO/branches
>
> svn co file://$REPO wc
>
> touch wc/trunk/file
>
> ln -s file wc/trunk/link
>
> svn add wc/trunk/file wc/trunk/link
>
> svn ci -m "link" wc
>
> svn cp -m "branch 1.0" file://$REPO/trunk file://$REPO/branches/1.0
>
> svn up wc
>
> svn rm wc/branches/1.0/link
>
> svn ci -m "rm link" wc
>
> svn merge --reintegrate ^/branches/1.0 wc/trunk
>
> --- Merging differences between repository URLs into 'wc/trunk':
>
>C wc/trunk/link
>
> --- Recording mergeinfo for merge between repository URLs into
> 'wc/trunk':
>
> U wc/trunk
>
> Summary of conflicts:
>
> Tree conflicts: 1
>
>
>
> The same when executed with svn, version 1.6.17 (r1128011)
>
> #Only the last command differs
>
> svn merge --reintegrate ^/branches/1.0 wc/trunk
>
> --- Merging differences between repository URLs into 'wc/trunk':
>
> Dwc/trunk/link
>
>
>
> Is this really a bug? Or am I doing something wrong?
>
>
>
> Regards
>
> Christian Asmussen
Thanks very much. Yes, this is a bug and I can reproduce it with the
current trunk code.
Can you file an issue in our tracker so this doesn't fall through the
cracks? See http://subversion.apache.org/issue-tracker.html Cheers!
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
RE: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links
Dear *, I was happy to see subversion 1.7.3 was release and that many bugs were fixed. This bug did not get fixed though (http://subversion.tigris.org/issues/show_bug.cgi?id=4052) and that would have made me even happier J Has anyone had time to look into this? Regards Christian Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases.
RE: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links
Thank you very much Stefan! Will try out the patch. Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases.
