You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Denis Excoffier <ap...@Denis-Excoffier.org> on 2019/02/28 21:44:25 UTC
Replacing directory by circular symlink produces malformed XML
Hello,
The situation of the replacement of a directory by a circular symlink
generates an XML fragment which is invalid, hence triggers a failure
within the calling system. See hereafter the recipe.
Starting from a clean folder, do the following:
% svn mkdir 1
A 1
% rmdir 1
% ln -s 1 1
% touch 2
% svn status --xml
<?xml version="1.0" encoding="UTF-8"?>
<status>
<target
path=".">
<entry
path="1">
<wc-status
item="obstructed"
revision="-1"
props="none">
</wc-status>
</entry>
svn: E000062: Can't open directory '/Users/dexco/svntest/svn/1': Too many levels of symbolic links
%
There is a missing end tag for <target> and <status>.
Another issue is missing output: path '2' is not listed.
The correction of these issues will be much appreciated (i use 1.11.1).
Regards,
Denis Excoffier.
Re: Replacing directory by circular symlink produces malformed XML
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Denis Excoffier wrote on Sat, 02 Mar 2019 09:17 +00:00:
> What would be the best strategy? I can figure out this one:
>
> 1) Within the working copy, delete the existing tree (not svn delete)
> 2) Extract the new tree at the same place
> 3) Interpret the result of 'svn status' in terms of 'svn add' and
> 'svn delete' to apply on the working copy (details omitted here)
> 4) Commit
>
That should work, though the 'svn status' will be expensive because the
usual optimization (not read()ing a file in full if its size+mtime
haven't changed) won't kick in.
In step 3 you can do 'svn add --force ./'.
There's an addremove branch [1] that attempts to implement this, but I
don't know what its state is. (It's named after the analogous hg command.)
[1] https://svn.apache.org/viewvc/subversion/branches/addremove/
> The difficulty is to make sure that all peculiarities of a file system
> changes (say: only files, folders and symlinks) are handled properly.
> I don't talk about I/O errors of course.
Yeah, I see no reason why it shouldn't be possible to version circular
symlinks. You can certainly create them with svnmucc, for example.
Cheers,
Daniel
Re: Replacing directory by circular symlink produces malformed XML
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 1, 2019, at 15:54, Denis Excoffier wrote:
> I have access to the source tree of some development project that is
> *not* under any version control system. I would like to build a
> minimal level of versioning by committing this source tree into
> Subversion at regular intervals, e.g. each day (automatically).
>
> What would be the best strategy? I can figure out this one:
>
> 1) Within the working copy, delete the existing tree (not svn delete)
> 2) Extract the new tree at the same place
> 3) Interpret the result of 'svn status' in terms of 'svn add' and
> 'svn delete' to apply on the working copy (details omitted here)
> 4) Commit
Another method to consider is the svn_load_dirs.pl script.
https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
Re: Replacing directory by circular symlink produces malformed XML
Posted by Denis Excoffier <ap...@Denis-Excoffier.org>.
> On 2019-03-01 11:53, Stefan Sperling wrote:
>
>>
>
> Hi Denis,
>
> This problem is not specific to symbolic links.
> There are quite a few cases where --xml produces invalid XML
> when it runs into some kind of error. Perhaps the command
> line client should be fixed to close open XML tags when an
> error occurs, though this also risks people or scripts not
> noticing such errors.
>
Thanks, but let's me explain it otherwise:
I have access to the source tree of some development project that is
*not* under any version control system. I would like to build a
minimal level of versioning by committing this source tree into
Subversion at regular intervals, e.g. each day (automatically).
What would be the best strategy? I can figure out this one:
1) Within the working copy, delete the existing tree (not svn delete)
2) Extract the new tree at the same place
3) Interpret the result of 'svn status' in terms of 'svn add' and
'svn delete' to apply on the working copy (details omitted here)
4) Commit
The difficulty is to make sure that all peculiarities of a file system
changes (say: only files, folders and symlinks) are handled properly.
I don't talk about I/O errors of course.
Denis Excoffier.
Re: Replacing directory by circular symlink produces malformed XML
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Fri, Mar 01, 2019 at 12:08:41 +0100:
> On 01.03.2019 11:53, Stefan Sperling wrote:
> > On Thu, Feb 28, 2019 at 10:44:25PM +0100, Denis Excoffier wrote:
> >> Hello,
> >>
> >> The situation of the replacement of a directory by a circular symlink
> >> generates an XML fragment which is invalid, hence triggers a failure
> >> within the calling system. See hereafter the recipe.
> >>
> >> Starting from a clean folder, do the following:
> >>
> >> % svn mkdir 1
> >> A 1
> >> % rmdir 1
> >> % ln -s 1 1
> >> % touch 2
> >> % svn status --xml
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <status>
> >> <target
> >> path=".">
> >> <entry
> >> path="1">
> >> <wc-status
> >> item="obstructed"
> >> revision="-1"
> >> props="none">
> >> </wc-status>
> >> </entry>
> >> svn: E000062: Can't open directory '/Users/dexco/svntest/svn/1': Too many levels of symbolic links
> >> %
> >>
> >> There is a missing end tag for <target> and <status>.
> >> Another issue is missing output: path '2' is not listed.
> >>
> >> The correction of these issues will be much appreciated (i use 1.11.1).
> >>
> >> Regards,
> >>
> >> Denis Excoffier.
> > Hi Denis,
> >
> > This problem is not specific to symbolic links.
> > There are quite a few cases where --xml produces invalid XML
> > when it runs into some kind of error. Perhaps the command
> > line client should be fixed to close open XML tags when an
> > error occurs, though this also risks people or scripts not
> > noticing such errors.
> >
> > I suppose that, ideally, our XML output would embed errors
> > inside the XML stream in a well-defined manner, as well as
> > printing errors on stderr.
> >
> > So fixing this would require some non-trivial amount of effort.
> > Would you have time and skills to work on this issue?
>
> My advice is to leave well enough alone. Any callers of our tools
> _should_ check the exit code before assuming that the output is valid.
> Just streaming the output through a SAX parser isn't the best strategy.
But there could have been tens of modified or unversioned <entry>s
before the circular symlink. The size of output is O(N) where N is the
number of interesting items found in the wc walk (= the number of lines
in the non-XML `svn st` output). Internally we always process trees
streamily; shouldn't we assume API consumers process trees streamily too?
Secondly, I don't understand why there's an error at all. Shouldn't it
just report an obstruction (dirent's svn_kind_t value changed) and move on?
Cheers,
Daniel
Re: Replacing directory by circular symlink produces malformed XML
Posted by Branko Čibej <br...@apache.org>.
On 01.03.2019 11:53, Stefan Sperling wrote:
> On Thu, Feb 28, 2019 at 10:44:25PM +0100, Denis Excoffier wrote:
>> Hello,
>>
>> The situation of the replacement of a directory by a circular symlink
>> generates an XML fragment which is invalid, hence triggers a failure
>> within the calling system. See hereafter the recipe.
>>
>> Starting from a clean folder, do the following:
>>
>> % svn mkdir 1
>> A 1
>> % rmdir 1
>> % ln -s 1 1
>> % touch 2
>> % svn status --xml
>> <?xml version="1.0" encoding="UTF-8"?>
>> <status>
>> <target
>> path=".">
>> <entry
>> path="1">
>> <wc-status
>> item="obstructed"
>> revision="-1"
>> props="none">
>> </wc-status>
>> </entry>
>> svn: E000062: Can't open directory '/Users/dexco/svntest/svn/1': Too many levels of symbolic links
>> %
>>
>> There is a missing end tag for <target> and <status>.
>> Another issue is missing output: path '2' is not listed.
>>
>> The correction of these issues will be much appreciated (i use 1.11.1).
>>
>> Regards,
>>
>> Denis Excoffier.
> Hi Denis,
>
> This problem is not specific to symbolic links.
> There are quite a few cases where --xml produces invalid XML
> when it runs into some kind of error. Perhaps the command
> line client should be fixed to close open XML tags when an
> error occurs, though this also risks people or scripts not
> noticing such errors.
>
> I suppose that, ideally, our XML output would embed errors
> inside the XML stream in a well-defined manner, as well as
> printing errors on stderr.
>
> So fixing this would require some non-trivial amount of effort.
> Would you have time and skills to work on this issue?
My advice is to leave well enough alone. Any callers of our tools
_should_ check the exit code before assuming that the output is valid.
Just streaming the output through a SAX parser isn't the best strategy.
-- Brane
Re: Replacing directory by circular symlink produces malformed XML
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Feb 28, 2019 at 10:44:25PM +0100, Denis Excoffier wrote:
> Hello,
>
> The situation of the replacement of a directory by a circular symlink
> generates an XML fragment which is invalid, hence triggers a failure
> within the calling system. See hereafter the recipe.
>
> Starting from a clean folder, do the following:
>
> % svn mkdir 1
> A 1
> % rmdir 1
> % ln -s 1 1
> % touch 2
> % svn status --xml
> <?xml version="1.0" encoding="UTF-8"?>
> <status>
> <target
> path=".">
> <entry
> path="1">
> <wc-status
> item="obstructed"
> revision="-1"
> props="none">
> </wc-status>
> </entry>
> svn: E000062: Can't open directory '/Users/dexco/svntest/svn/1': Too many levels of symbolic links
> %
>
> There is a missing end tag for <target> and <status>.
> Another issue is missing output: path '2' is not listed.
>
> The correction of these issues will be much appreciated (i use 1.11.1).
>
> Regards,
>
> Denis Excoffier.
Hi Denis,
This problem is not specific to symbolic links.
There are quite a few cases where --xml produces invalid XML
when it runs into some kind of error. Perhaps the command
line client should be fixed to close open XML tags when an
error occurs, though this also risks people or scripts not
noticing such errors.
I suppose that, ideally, our XML output would embed errors
inside the XML stream in a well-defined manner, as well as
printing errors on stderr.
So fixing this would require some non-trivial amount of effort.
Would you have time and skills to work on this issue?
Thanks,
Stefan
Re: Replacing directory by circular symlink produces malformed XML
Posted by Branko Čibej <br...@apache.org>.
On 28.02.2019 22:44, Denis Excoffier wrote:
> Hello,
>
> The situation of the replacement of a directory by a circular symlink
> generates an XML fragment which is invalid, hence triggers a failure
> within the calling system. See hereafter the recipe.
>
> Starting from a clean folder, do the following:
>
> % svn mkdir 1
> A 1
> % rmdir 1
> % ln -s 1 1
> % touch 2
> % svn status --xml
> <?xml version="1.0" encoding="UTF-8"?>
> <status>
> <target
> path=".">
> <entry
> path="1">
> <wc-status
> item="obstructed"
> revision="-1"
> props="none">
> </wc-status>
> </entry>
> svn: E000062: Can't open directory '/Users/dexco/svntest/svn/1': Too many levels of symbolic links
> %
>
> There is a missing end tag for <target> and <status>.
> Another issue is missing output: path '2' is not listed.
>
> The correction of these issues will be much appreciated (i use 1.11.1).
You can't expect valid output from a command that fails. I'd have
thought that was obvious?
-- Brane