Re: Overwrite a file with svn update?

2005-11-20 Thread Hans-Peter Nilsson
On Sat, 19 Nov 2005, Steve Kargl wrote:
 On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
 I believe if the file is in a cvs repository and the copy
 in your local tree was not obtained via a checkout, cvs
 will replace the local file with whatever is in the repository.

No, it'll continue to update the rest of the tree but emit an
error (i.e. not bail out immediately like svn).  IIRC.

  However, if I'm understanding it right, here Subversion is hesitating
  to replace a file with a file of the same name whose contents are the
  same.  Is that correct?

 Yes.

I see this regularly too, like when I write a test-case in
another tree than where I'll commit it and forget to remove it
before the next update of the first tree.  I like Jim Blandy's
suggestion that svn could just emit some informational
message if the contents is the same as the some revision (first
or HEAD presumably) and just go on.

brgds, H-P


Re: Overwrite a file with svn update?

2005-11-20 Thread Andreas Schwab
Hans-Peter Nilsson [EMAIL PROTECTED] writes:

 On Sat, 19 Nov 2005, Steve Kargl wrote:
 On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
 I believe if the file is in a cvs repository and the copy
 in your local tree was not obtained via a checkout, cvs
 will replace the local file with whatever is in the repository.

 No, it'll continue to update the rest of the tree but emit an
 error (i.e. not bail out immediately like svn).  IIRC.

If the local file is identical to the check-out version then there is no
error and the local file becomes a version-controlled file.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


Re: Overwrite a file with svn update?

2005-11-20 Thread Hans-Peter Nilsson
On Sun, 20 Nov 2005, Andreas Schwab wrote:
 Hans-Peter Nilsson [EMAIL PROTECTED] writes:
  On Sat, 19 Nov 2005, Steve Kargl wrote:
  On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
  I believe if the file is in a cvs repository and the copy
  in your local tree was not obtained via a checkout, cvs
  will replace the local file with whatever is in the repository.
 
  No, it'll continue to update the rest of the tree but emit an
  error (i.e. not bail out immediately like svn).  IIRC.

 If the local file is identical to the check-out version then there is no
 error and the local file becomes a version-controlled file.

I've never seen this, always the collision message, so I guess
it's version-dependent.

brgds, H-P


Re: Overwrite a file with svn update?

2005-11-20 Thread Andreas Schwab
Hans-Peter Nilsson [EMAIL PROTECTED] writes:

 I've never seen this, always the collision message, so I guess
 it's version-dependent.

It appears to work only with a local repository.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


Overwrite a file with svn update?

2005-11-19 Thread Steve Kargl
Perhaps, I missed the required options, but I'll
ask an obvious question anyway.  Often when testing
a patch, one will often place a new testcase in
gcc/testsuite/*.  This new file is not under control
of svn.  After review, the patch is committed to the
tree.  Now, I want to update my local repository.
I issue svn update and the result is

svn: Failed to add file 'gcc/testsuite/gfortran.dg/fgetc_1.f90': \
object of the same name already exists

which is indeed correct.  So, is there an option to tell
svn to blow away files that conflict with files in the
repository.

-- 
Steve


Re: Overwrite a file with svn update?

2005-11-19 Thread Jim Blandy
On 11/19/05, Steve Kargl [EMAIL PROTECTED] wrote:
 which is indeed correct.  So, is there an option to tell
 svn to blow away files that conflict with files in the
 repository.

Subversion is reluctant to blow away users' files; this was one of the
qualities of CVS we thought we should try to retain.

However, if I'm understanding it right, here Subversion is hesitating
to replace a file with a file of the same name whose contents are the
same.  Is that correct?  It seems to me like Subversion could
reasonably handle that the same way it does when an update brings in
textual changes to an existing file that already has those changes in
it: it says, Oh, you have this already and doesn't worry about it.

Has the file in your local repository been added with 'svn add'?  Or
is it an unknown file from Subversion's point of view?


Re: Overwrite a file with svn update?

2005-11-19 Thread Giovanni Bajo
Steve Kargl [EMAIL PROTECTED] wrote:

 Perhaps, I missed the required options, but I'll
 ask an obvious question anyway.  Often when testing
 a patch, one will often place a new testcase in
 gcc/testsuite/*.  This new file is not under control
 of svn.  After review, the patch is committed to the
 tree.  Now, I want to update my local repository.
 I issue svn update and the result is

 svn: Failed to add file 'gcc/testsuite/gfortran.dg/fgetc_1.f90': \
 object of the same name already exists

 which is indeed correct.  So, is there an option to tell
 svn to blow away files that conflict with files in the
 repository.


Why don't you just svn add the file? So you won't miss it in the commit, in
the diffs, in the stats, and whatnot. svn add is a totally local operation
and does not require write access to the remote repository. You can even do
that on a tree checked out with svn:// and later switch the tree to svn+ssh://
to commit it.

Giovanni Bajo



Re: Overwrite a file with svn update?

2005-11-19 Thread Steve Kargl
On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
 On 11/19/05, Steve Kargl [EMAIL PROTECTED] wrote:
  which is indeed correct.  So, is there an option to tell
  svn to blow away files that conflict with files in the
  repository.
 
 Subversion is reluctant to blow away users' files; this was one of the
 qualities of CVS we thought we should try to retain.

I believe if the file is in a cvs repository and the copy
in your local tree was not obtained via a checkout, cvs
will replace the local file with whatever is in the repository.

 However, if I'm understanding it right, here Subversion is hesitating
 to replace a file with a file of the same name whose contents are the
 same.  Is that correct?

Yes.

 Has the file in your local repository been added with 'svn add'?

No.

 Or is it an unknown file from Subversion's point of view?

Yes.


The scenario is:

Committer1:  I have a patch with a new file that needs review.
Committer2:  Grabs patch and put everything in local tree to review.
Committer2:  Does not use svn add or any other svn command.
Committer2:  Finishes review and tells committer1 to check patch in.
Committer1:  Commits patch
Committer2:  Now wants to update his local repository.  Files conflict.

-- 
Steve


Re: Overwrite a file with svn update?

2005-11-19 Thread Steve Kargl
On Sat, Nov 19, 2005 at 09:00:38PM +0100, Giovanni Bajo wrote:
 Steve Kargl [EMAIL PROTECTED] wrote:
 
  Perhaps, I missed the required options, but I'll
  ask an obvious question anyway.  Often when testing
  a patch, one will often place a new testcase in
  gcc/testsuite/*.  This new file is not under control
  of svn.  After review, the patch is committed to the
  tree.  Now, I want to update my local repository.
  I issue svn update and the result is
 
  svn: Failed to add file 'gcc/testsuite/gfortran.dg/fgetc_1.f90': \
  object of the same name already exists
 
  which is indeed correct.  So, is there an option to tell
  svn to blow away files that conflict with files in the
  repository.
 
 
 Why don't you just svn add the file? So you won't miss it in the commit, in
 the diffs, in the stats, and whatnot. svn add is a totally local operation
 and does not require write access to the remote repository. You can even do
 that on a tree checked out with svn:// and later switch the tree to svn+ssh://
 to commit it.

This is during a review process.  There is no guarantee that
file will be committed.  Additionally, by keeping the file
out of svn, it severely reduces the probability of accidental
commit.

-- 
Steve