Some Defects

[Mark Watts <mw...@stny.rr.com>]

Running WinXP (SP1)
Subversion 0.23

1.  Doing 'svn merge --dry-run -r 89:124 file:///c:/svn/repos/trunk' results
in the following error message

     svn: Working copy not locked
     svn: no write-lock in: src

  now if I do a regular merge it goes past this point just fine however the
item that would have been printed had the dry run worked is:
D            src\file1.txt

  Note also the excessive indentation of the deleted directory and filename

2.  If for some reason the merge fails and you do a 'svn revert -R .' on the
tree to put everything back, files that have been added as part of the merge
are not deleted.  When you attempt the merge again it fails because of an
"Obstructed update".  NOTE: I think I may have seen something about this
already being reported an in the issue tracker but I could not find it when
I looked.

3.  If the trunk has a new directory that has been added, in my case
'\trunk\bin', and then the 'bin' directory has had the svn:ignore property
set on it to ignore *.* in that directory, when the merge is done the 'bin'
directory is added correctly to the trunk but I also have  conflict report
for the bin directory with the followin message (2 lines):
-------start of message
prop `svn:ignore': user deleted, but update sets it to '*.*
'.
-------end of message
  a. note the use of '`' in `svn:ignore' instead of the single quote char
  b. why is the message continued on a second line?
  c. why is the conflict reported at all?  The directory did not exist in
the branch and was added by the merge.

  NOTE:  This MAY be related to issues 1319 and 838 but I don't know enough
yet to be sure.

Sorry for reporting these if they are already known


Thanks
 
-Mark


-Mark
 



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

Re: Some Defects

[Philip Martin <ph...@codematters.co.uk>]

"Mark Watts" <mw...@stny.rr.com> writes:

> However, I have a new question.  When a merge fails, as it did in this
> situation, it can leave the working copy in an unknown state.

Unknown?  The status command should work.  The merge command lists the
items it affects. Those should be enough to allow you to determine the
working copy state.

> I used 'svn revert' as the means to try and bring the working copy
> back to a known state and from what you are both saying it did so as
> far as the subversion meta-data in '.svn' directories was concerned
> AND as far as reverting modified or deleted files to the state they
> were at prior to the merge.

Not quite.  If the working copy file had local changes before the
merge then running revert will undo both the merge and the local
changes.

> However, because the add was done and then unscheduled the revert didn't
> really 'undo' the merge completely.  Right?  What is the standard way to
> correct this situation?

There is no general way to undo a merge automatically.  If there were
no local modifications prior to the merge, and if no conflicts created
during the merge, then the command

  svn merge -rX:Y URL wc

could be reversed using

  svn merge -rY:X URL wc

There is one slight disadvantage to this, if any of the merged files
end up without local changes then the text-base timestamps recorded in
the entries file will not identify those files as unmodifed.  Until
the timestamp gets updated Subversion will fall back to a byte
comparison of file and text-base.

-- 
Philip Martin

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

RE: Some Defects

[Mark Watts <mw...@stny.rr.com>]

> -----Original Message-----
> From: sussman@collab.net [mailto:sussman@collab.net] 
> Sent: Friday, May 30, 2003 14:15
> To: dev@subversion.tigris.org
> 
> Philip Martin <ph...@codematters.co.uk> writes:
> 
> > > 2.  If for some reason the merge fails and you do a 'svn 
> revert -R 
> > > .' on the tree to put everything back, files that have 
> been added as 
> > > part of the merge are not deleted.
> > 
> > That is how revert is intended to work.
> 
> Correct.
> 
> II create a new file, and 'svn add' it.  Then I change my 
> mind;  I don't want to put it under version control after 
> all.  When I run 'svn revert', it removes the scheduling 
> only.  It would be awful if it deleted the file -- the data 
> would be gone forever.

OK.  I can see that and agree.  

However, I have a new question.  When a merge fails, as it did in this
situation, it can leave the working copy in an unknown state.  I used 'svn
revert' as the means to try and bring the working copy back to a known state
and from what you are both saying it did so as far as the subversion
meta-data in '.svn' directories was concerned AND as far as reverting
modified or deleted files to the state they were at prior to the merge.
However, because the add was done and then unscheduled the revert didn't
really 'undo' the merge completely.  Right?  What is the standard way to
correct this situation?

-Thanks

-Mark



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

Re: Some Defects

[Ben Collins-Sussman <su...@collab.net>]

Philip Martin <ph...@codematters.co.uk> writes:

> > 2.  If for some reason the merge fails and you do a 'svn revert -R
> > .' on the tree to put everything back, files that have been added
> > as part of the merge are not deleted.
> 
> That is how revert is intended to work.

Correct.

II create a new file, and 'svn add' it.  Then I change my mind;  I
don't want to put it under version control after all.  When I run 'svn
revert', it removes the scheduling only.  It would be awful if it
deleted the file -- the data would be gone forever.

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

Re: Some Defects

[Philip Martin <ph...@codematters.co.uk>]

"Mark Watts" <mw...@stny.rr.com> writes:

> 1.  Doing 'svn merge --dry-run -r 89:124 file:///c:/svn/repos/trunk' results
> in the following error message
>
>      svn: Working copy not locked
>      svn: no write-lock in: src
>
>   now if I do a regular merge it goes past this point just fine however the
> item that would have been printed had the dry run worked is:
> D            src\file1.txt

I believe I fixed this a couple of days ago.

> 2.  If for some reason the merge fails and you do a 'svn revert -R .' on the
> tree to put everything back, files that have been added as part of the merge
> are not deleted.

That is how revert is intended to work.

-- 
Philip Martin

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