On 03/06/13 13:31, Markus Schaber wrote:
Hi, Peter,
Von: Peter Weinert [mailto:peter.wein...@gns-mbh.com]
system: linux
subversion: v1.7.x
this problem starts when using version 1.7 of subversion.
until 1.6 every sub-dir had its own '.svn', so wherever i was, all
information to commit update was available.
now there's only one, where one checked out the repo.
In my eyes, the fact that SVN changed to a single .svn directory is a big
advantage, brings SVN on par to other RCSes in this area, and should not be
reverted back. :-)
it sure is a good idea to have everything in one place as this speeds things up a lot... having thousands of files to
work with is rarely preferable...
Additionally, SVN normally finds its way up to the working copy root when you
issue a command in a subdirectory (try it by cd'ing to the destination of your
symlink and then issuing the commit command there), so this change itself is
not the cause for your problems.
sorry, wasn't checkin.. was "svn delete", command is following (where
"tester_gui_ref" is the symbolic link) :
svn --non-interactive --force delete
/home/animator/bin/QA-utils/HTML-Report/./tester_gui_ref/test-cases/pic/ide_nhi/message.ref
svn: E155007: '/home/animator/bin/QA-utils/HTML-Report/tester_gui_ref/test-cases/pic/ide_nhi/message.ref' is not a
working copy
this is problematic when having somewhere else a symbolc-link to a sub-dir of
that checkout.
it's impossible to do anything with svn on that link because svn can't find
the repository data and always returns:
svn: E155007: ' .... filename ..... ' is not a working copy
because of many automated process / web-server-scripts / etc. that access the
data in our case, it would be very beneficient if such things would still be
possible with svn 1.7... otherwise we'd be stuck with last release of v1.6,
because it would mean to rewrite a very large amount of scripts to adapt to
such changes...
What's the exact use case of using those symlinks?
there's a test environment which has data for current test run and each machine and global & "special" (for single
machine) reference data.. managing this data through the web-interface (adding, removing, updating, ... references)
should now be independent of source and target... therefore there are links into the homogenous part of the data...
Could you add a wrapper shell script which follows the symlink by changing the
current directory to its destination, and then issue the command from there?
Or resolve the symlink, and pass the absolute destination path to the SVN
command?
already tested some stuff with the ls-command, but no option in the manpage
helped yet (ls -H, ls -L, ..)...
suggestion: have a symbolic link (on supported systems, like linux, unix,
etc.) that points to the .svn-dir where the base-path of the checkout can be
determined and therefore the repositry-url, etc.
Adding those symbolic links seems to clutter the working directories for a
questionable benefit (e. G. imagine someone moving or renaming a subdirectory
of a WC using shell commands - the contained symlink would be broken than, and
confuse SVN and users even more.
yep, was just a quick shot / first idea... but working on subversioned files without using svn always broke some
stuff... some easier, some harder to repair...
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store:
http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade
register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Mit freundlichen Grüßen / Best Regards
Peter Weinert
GNS mbH Tel.: +49-(0)-531-80112-35
Am Gaußberg 2 Fax : +49-(0)-531-80112-79
38114 Braunschweig mailto:peter.wein...@gns-mbh.com
http://www.gns-mbh.com/
Sitz und Amtsgericht Braunschweig HRB 4004
Steuernummer 14/203/31601
VAT-Id. DE173536746
Geschäftsführer: Stefan Hanson, Klaus Radtke, Claudius Schöne
