Re: Migrating ClearCase data to Subversion
Thanks All for your help, I will try the Polarion tool, I am also looking at simplified ways to do the job. I have to propose a solution for projects asking to migrate from CC to SVN, on Unix and Windows. And we cannot let the ClearCase vob live forever - maybe one year, not more, because ClearCase is expensive, and we cannot administer two repositories for every project. Most of the time, projects are not interested to keep all SCM details, they don't ask for preserving change dates, authors or even comments (afaik). Projects would like to get the versions that were delivered, the major versions and especially the version running in production. I don't think there is real sensitive data, but there is surely binaries - I cannot avoid them. Vob's size is sometimes big, tens of Gb, or more. They need to get in the new repository : - The main=trunk branch, - All the other significant integration branch, - And the label/tag lines on these main and integration branches. The project will select : the branches and the labels to migrate. I'd like to preserve : - The relation (svn copy) between branches, and between labels/tags and branches. - The refactoring from a version to another on a same branch (svn mv/rm). I think I will create one SVN revision per label/tag. I have to read again the manual about svn properties to understand what to do !
RE: Method not allowed exception
Sorry for top-posting, but although Brane is right, he's not being as helpful as he could. Stefano, I had pretty much the same issue. A workaround is to only do actions (other than Commit) on unlocked working copies. That is, before doing a copy (in particular), make sure all locks are released. The fix that worked for me was to update the server. I downloaded the Wandisco server binaries (which are patched with the fix to this issue) and then copied mod_dav*.so to the modules directory of the Apache installation that we have actually working. (Ideally, I'd just install and run the Wandisco binaries, but with our configuration it was easiest to get working by just doing the copy.) Regards, Geoff From: Branko Čibej Sent: Friday, 15 November 2013 18:09 PM To: users@subversion.apache.org Subject: Re: Method not allowed exception On 15.11.2013 07:47, Stefano Fraccaro wrote: Il 14/11/2013 22:35, Ben Reser ha scritto: Can you elaborate what method you're seeing method not allowed with? Or if you were running a svn client what command you were running? TortoiseSVN > SVN Checkout The one case where we made such a change that comes to mind is with LOCK. LOCK per the RFC can lock files that don't exist (otherwise known as an unmapped url or null resources). http://webdav.org/specs/rfc4918.html#lock-unmapped-urls http://webdav.org/specs/rfc2518.html#rfc.section.7.4 We only support this when SVNAutoversioning is turned on and return a method not allowed error if this isn't turned on. We felt that the method not allowed error was the logical error to return. The other cases where we return method not allowed typically are cases where we don't allow that method on regular URLs unless auto-versioning is enabled. We have an apache installation with subversion modules ( http://webserver/ ). All our repositories are in svn subfolder ( http://webserver/svn/RepositoryName ) If I checkout the url 'http://webserver/badname/RepositoryName', subversion return '405 Method not allowed' instead of '404 Url not found'. Unexpected HTTP status 405 Method Not Allowed on '/badname/RepositoryName' Additional errors: PROPFIND request on '/badname/RepositoryName' failed: 405 Method not allowed I think you are mistaken, this error probably not returned by Subversion (since it's not configured on that location) but by the Apache HTTPd server itself. Most likely your server interprets the request as a PROPFIND on directory "badname" within the directory defined by the server configuration option DocumentRoot. The default server configuration probably only allows GET requests on such paths; which makes a kind of sense, since the PROPFIND method is defined by the DAV protocol, not HTTP itself. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
Re: Method not allowed exception
On 11/17/13 2:12 PM, Geoff Field wrote: > Sorry for top-posting, but although Brane is right, he's not being as helpful > as he could. > > Stefano, I had pretty much the same issue. A workaround is to only do > actions (other than Commit) on unlocked working copies. That is, before > doing a copy (in particular), make sure all locks are released. > > The fix that worked for me was to update the server. I downloaded the > Wandisco server binaries (which are patched with the fix to this issue) and > then copied mod_dav*.so to the modules directory of the Apache installation > that we have actually working. (Ideally, I'd just install and run the > Wandisco binaries, but with our configuration it was easiest to get working > by just doing the copy.) Your issue and the one he is having aren't similar at all. He was trying to do a checkout against a URL that isn't directed at Subversion. Subversion uses HTTP methods that normally aren't typically used by a web browser. As a result Apache HTTPD rejected the request by the Subversion client with a Method Not Allowed (405) error rather than a Not Found (404) error as he was expecting. This is normal behavior of Apache httpd (though perhaps we could improve our error message to help a user realize this probably means they're using the wrong URL or the server is misconfigured). The problem you're describing is this bug with mod_dav: https://issues.apache.org/bugzilla/show_bug.cgi?id=55306 Which happens when you try to commit a copy of a file that is locked and ended up getting a Failed Dependency (424) error. That issue will be fixed in 2.2.26 and 2.4.7 when they come out.
RE: Method not allowed exception
> From: Ben Reser > On 11/17/13 2:12 PM, Geoff Field wrote: > > Sorry for top-posting, but although Brane is right, he's > not being as helpful as he could. [snip] > Your issue and the one he is having aren't similar at all. > > He was trying to do a checkout against a URL that isn't > directed at Subversion. > Subversion uses HTTP methods that normally aren't typically > used by a web browser. As a result Apache HTTPD rejected the > request by the Subversion client with a Method Not Allowed > (405) error rather than a Not Found (404) error as he was > expecting. This is normal behavior of Apache httpd (though > perhaps we could improve our error message to help a user > realize this probably means they're using the wrong URL or > the server is misconfigured). [snip] I sit corrected. Why am I not surprised that I got the wrong end of the stick? ;-) Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
Empty rpath when attempting make swig-py
Hi, I am trying to build the swig python bindings for subversion on Mac OS X. I downloaded source for subversion from here: http://opensource.apple.com/release/os-x-109/ I ran configure as follows: ./configure --prefix=/usr --with-swig --enable-swig-bindings=python Make works. But then, when I run: make swig-py I get the following error from libtool cd subversion/bindings/swig/python/libsvn_swig_py && /bin/sh /Users/fred/sandbox/subversion-52/subversion/libtool --tag=CC --silent --mode=link gcc -g -O2 -rpath -bundle -undefined dynamic_lookup -Wl,-F. -o libsvn_swig_py-1.la swigutil_py.lo ../../../../../subversion/libsvn_client/libsvn_client-1.la../../../../../subversion/libsvn_wc/ libsvn_wc-1.la ../../../../../subversion/libsvn_ra/libsvn_ra-1.la../../../../../subversion/libsvn_delta/ libsvn_delta-1.la ../../../../../subversion/libsvn_subr/libsvn_subr-1.la-L/usr/lib -R/usr/lib -laprutil-1 -lldap -llber -llber-lexpat -liconv -lsqlite3-lldap -llber -llber -L/usr/lib -R/usr/lib -lapr-1 -lpthread -framework Security -framework CoreFoundation -framework CoreServices libtool: link: only absolute run-paths are allowed make: *** [subversion/bindings/swig/python/libsvn_swig_py/ libsvn_swig_py-1.la] Error 1 I think this is because -rpath doesn't have anything after it. I looked at the swig-py target in the Makefile and found the following: swig-py: autogen-swig-py copy-swig-py I can't find the target autogen-swig-py in the Makefile. Can anyone tell me where I can find this target defined? Is there somewhere else I should look to find why -rpath is empty above? I am not subscribed to the subversion users e-mail list. I would appreciate being Cc:ed in any responses. Thank you, Jason Mazzotta
Re: svnmucc
BZ> The reason to support this syntax with command and arg on separate lines BZ> is to support files with whitespaces in the names But what about quotes? Most OSes and programs accept quoted file names containing spaces. Single-line commands are more readable, IMHO. -- WBR, Vladislav Javadov
