On Sun, 12 Jul 2020 at 15:26, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>
> sebb wrote on Tue, 07 Jul 2020 20:43 +0100:
> > When I first started using svnmucc, it used to be the case that
> > svnmucc 'put' --revision 0 would fail if the target file already
> > existed. This no longer happens.
> >
>
> Is the file-to-be's parent directory the root directory?
No, it's not.
> If that isn't the case, then the new behaviour is correct.
Why is that?
> You might wish to post the error message.
Just tried with a local SVN repo:
$ svnmucc -mBug --revision 0 -- put /dev/null
file:///var/tools/svnrep/asf/x/b.tmp
svnmucc: E160016: Can't commit to 'file:///var/tools/svnrep/asf/x'
because it is not a directory
That message is wrong, because /x/ *is* a directory.
The same error occurs regardless of whether b.tmp is present.
> > The previous behaviour was very useful, so are there any plans to reinstate it?
> >
>
> Patches welcome. (You'll have to propose a new syntax, of course.)
--revision -1
> > I don't think there is a straightforward way to guarantee the same
> > behaviour now.
> >
>
> Try:
>
> svn checkout --depth=empty $URL wc
> cd wc
> svn up --set-depth=infinite iota
> touch iota
> svn add iota
> svn commit -mm
> svn up --set-depth=empty iota
> svn cleanup # prune .svn/pristine
Not exactly straightforward, but it does fail if the file has been
created meanwhile
However the error response still has to be analysed
Also the script can fail in at least two places, depending on when the
file is created.
> > The closest I could get is:
> >
> > 1) get current parent directory revision
> > 2) check if target file does not exist. This is not as easy as it
> > sounds, as the target directory may have too many files to list
> > efficiently, and any other file-based command may fail for a reason
> > other than a missing file.
>
> How is «svn info $URL/to/file@$REV» not sufficient? You can use
> $URL/to{,/file}@$REV if you want, too.
Same issue: svn info only returns success if the file exists.
An error may mean the file did not exist or something else, so the
error text has to be analysed.
> > 3) Put the file using the revision obtained in step 1.
> > AFAICT this is guaranteed not to replace an existing file.
> >
> > However it may fail to create the file if the target directory has
> > been updated in the meantime.
> >
> > It's only safe to repeat the attempted create if the command failed
> > due to an out of date revision.
> > So the failure reason will have to be analysed.
>
> What part of the above is a problem, and why?
It requires analysing the error response, which is likely to be fragile.
Received on 2020-07-12 17:56:08 CEST