You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/01/01 12:41:58 UTC

Re: 301 error on merge

On Mon, 2003-12-29 at 18:38, John Szakmeister wrote:
> On Saturday 20 December 2003 07:28, John Szakmeister wrote:
> >   if (! strcmp (targetpath, ""))
> >     {
["If source1 and source2 are files with the same basename, then..."]
> >               targetpath = sp1_basename;

> The current algorithm doesn't always pick the correct target...

I haven't seen the users thread; can you elaborate on that?  It would
seem to depend on what "correct" is.

> At the very least, I think that if I put '.' as the target for the 
> merge operation on the command line, that we should treat that as an explicit 
> target and not try to compute an implicit target.

Agreed, but...

> I think this gives users a more reasonable workaround than having to
> type 'svn merge URL1 URL2 ../name_of_current_directory'.

I'm missing something.  If URL1 and URL2 are both files, when would this
ever produce anything but an error?

(It certainly seems more appropriate to generate an error on "svn merge
url-of-file1 url-of-file2 ." than it is to try to merge into
basename-of-file1, so I agree that it's a bug.  But more of an
"unpredictable behavior in the corner case" bug than a usability bug.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 301 error on merge

Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 01 January 2004 12:24, Greg Hudson wrote:
> On Thu, 2004-01-01 at 09:47, John Szakmeister wrote:
> > > ["If source1 and source2 are files with the same basename, then..."]
>
> Ah, I understand now.  The actual test is:
>
>   If source1 and source2 have the same basename and that basename
>   maps to a file in the wc, then use that basename as the implicit
>   target.
>
> which is a terrible test.  I can see why you might want to move it into
> libsvn_client, where one could test the URLs rather than the working
> copy.

Yep.  But I think even if we move the test into libsvn_client, that we still 
face some problems.  We can never be absolutely sure what the target of the 
merge operation is supposed to be, unless it is specified.

-John


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 301 error on merge

Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-01-01 at 09:47, John Szakmeister wrote:
> > ["If source1 and source2 are files with the same basename, then..."]

Ah, I understand now.  The actual test is:

  If source1 and source2 have the same basename and that basename
  maps to a file in the wc, then use that basename as the implicit
  target.

which is a terrible test.  I can see why you might want to move it into
libsvn_client, where one could test the URLs rather than the working
copy.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: 301 error on merge

Posted by John Szakmeister <jo...@szakmeister.net>.
On Thursday 01 January 2004 07:41, Greg Hudson wrote:
> On Mon, 2003-12-29 at 18:38, John Szakmeister wrote:
> > On Saturday 20 December 2003 07:28, John Szakmeister wrote:
> > >   if (! strcmp (targetpath, ""))
> > >     {
>
> ["If source1 and source2 are files with the same basename, then..."]
>
> > >               targetpath = sp1_basename;
> >
> > The current algorithm doesn't always pick the correct target...
>
> I haven't seen the users thread; can you elaborate on that?  It would
> seem to depend on what "correct" is.

Take a look at:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=3816. 

In summary, if the URLs point to a directory (i.e., the goal here is merge 
changes at a directory level), but that directory happens to have the same 
name as a file in that directory and you haven't specified the target 
explicitly, then this algorithm fails.

> > At the very least, I think that if I put '.' as the target for the
> > merge operation on the command line, that we should treat that as an
> > explicit target and not try to compute an implicit target.
>
> Agreed, but...
>
> > I think this gives users a more reasonable workaround than having to
> > type 'svn merge URL1 URL2 ../name_of_current_directory'.
>
> I'm missing something.  If URL1 and URL2 are both files, when would this
> ever produce anything but an error?

The problem is that if the merge fails like it did in user thread, and you 
type 'svn merge URL1 URL2 .', the '.' is treated as an implicit target rather 
than an explicit one and we try to compute the target of the merge operation 
exactly the same way as if we had typed 'svn merge URL1 URL2'.  I tend to 
think that if I explicity tell you the target of the merge, that's what you 
should try to do.  Unfortunately, in the case you have to use a command like 
'svn merge URL1 URL2 ../name_of_current_directory' to prevent the command 
line client from attempting to compute the target of the merge.

> (It certainly seems more appropriate to generate an error on "svn merge
> url-of-file1 url-of-file2 ." than it is to try to merge into
> basename-of-file1, so I agree that it's a bug.  But more of an
> "unpredictable behavior in the corner case" bug than a usability bug.)

I guess I see 2 bugs.  "svn merge url-of-file1 url-of-file2 ." treat my 
explicit target the same as if I had not specified it at all.  And I see the 
case where the basename of the URL you're using matches the name of a file in 
your WC and the target of the merge is the directory, but we erroneously 
compute the target as being the file instead of the current directory.

I hope that helps in understanding the problem a little more.

-John


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org