Neels Hofmeyr wrote:
> > Heh. It was me who added that. It wasn't by accident. I was trying to
> > solve the problem of when the target is the root of the WC and therefore
> > there is no parent WC directory. However, I didn't properly solve that
> > problem, and I forgot to mention it in the log message, so we might very
> > well call it an accident.
>
> lol, sorry and thanks :)
>
> But, about when the target is the working copy root: that got me thinking.
> There is no parent directory to report conflicts in! And what will
> adm_retrieve return in such a case?
>
> This is the exact case:
> 1. Directory X has been issued on the svn commandline (e.g. `svn update X')
> 2. This directory X is a tree-conflict victim, and
> 3. X also happens to be the root of the local working copy.
>
> (It doesn't make sense to think of the repository root being a tree
> conflicts victim. Here, though, X has been checked out explicitly, and is
> the working copy root, as one would check out `trunk')
>
> There has been word that tree conflicts should be reported at the actual
> victim nodes, not in their respective parent directories. That would
> sufficiently prevent this problem altogether.
Bear in mind that "reported as" and "stored as" are two completely
different things. I'm not intending to change the storage, only the
reporting. The storage can stay in the parent directory.
> But for now, I tried to create conflicts in a working copy's root dir. It
> seems that at least update is waterproof, in a way. I've attached scripts
> that run the cases listed here, numbers corresponding:
>
>
> 1) Try to update the working copy root to a deleted revision (no conflicts):
> "svn: Target path does not exist"
>
> 2) Prop conflicts are handled as they should.
>
> 3) Run `svn rm .' in the working copy root and try to commit:
> States that the commit succeeded but warns about ugly problems.
> Status complains about a "missing" file removed by svn itself.
>
> 4) First run `svn rm .' in the working copy root, then try to update it to a
> deleted revision: same as 1): "svn: Target path does not exist".
> Also, `svn rm .' fails to lock a subdir, whatever that means.
>
> 5) First run `svn rm .' in the working copy root, then try to update it to a
> modified revision: same as 3): commit succeeded but warns about ugly
> problems. Also, the update "restores" a file removed by svn itself.
>
>
> It is pretty obvious that these cases are not considered valid. At least no
> user out there will run into the problem I am poking for here, because it
> doesn't even run that far, for other reasons.
>
> Have I missed a case? Otherwise everything is fair enough, at least from the
> tree-conflicts point of view ... switch and merge remain to be checked, but
> I expect the same stuff happening.
That sounds fair enough. Thanks for the scripts to demonstrate these
cases.
> > I made just one tweak: There was a point where you wrote "if
> > (svn_io_check_path(...) != SVN_NO_ERROR ..." which would leak the error
> > object if it threw an error. Instead, we have to call the function on
> > its own, as "SVN_ERR(svn_io_check_path(...));". Any error that it might
> > return is one that we don't know how to deal with, so it is OK to just
> > return the error to our caller.
>
> Ah yes, true. (Hasn't this been said before somewhere, too?)
Yes, Stefan said it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-09 21:53:10 CEST