You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mo DeJong <su...@bayarea.net> on 2001/12/07 10:22:51 UTC
A couple of problems with svn rm.
Hi all.
I have run into a couple of little problems with the svn rm command
and I thought I would ask about them before filing a new issue. I am
using the local file access layer here.
Assuming I just checked out a dir:
% echo BAR > bar.c
% % svn add bar.c
A bar.c
% svn st
A ./bar.c
% svn commit -m "added bar.c"
Adding /usr/tmp/subversion/checkout/project/head/bar.c
Commit succeeded.
% svn rm bar.c
D bar.c
% ls
bar.c foo.c
Now, why is bar.c still there? Why does the client fail to remove
the file?
And now the other problem:
% svn commit bar.c
svn_error: #21050 : <Filesystem has no such file>
commit failed: wc locks and tmpfiles have been removed.
svn_error: #21050 : <Filesystem has no such file>
commit failed: while sending tree-delta.
svn_error: #21050 : <Filesystem has no such file>
file not found: filesystem `/tmp/subversion/repo/db', transaction `2', path `/project/head/bar.c'
Issue 565 seems kind of like this problem, but they are not exactly the same. Is this a known
problem or should I file a new issue?
thanks
Mo DeJong
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A couple of problems with svn rm.
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Indeed, it's been filed forever. In fact, around here, we call it the
> 'add, commit, delete, commit' bug. It only exists in ra_local, and
> know exactly why it happens.
>
> For the next few weeks, just update after the first commit. It will
> be fixed soon.
Actually, Benny, let's start just calling it "the AC/DC bug". I've
grown to actually love that little booger.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A couple of problems with svn rm.
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> Mo DeJong <su...@bayarea.net> writes:
>
> > % svn rm bar.c
> > D bar.c
> > % ls
> > bar.c foo.c
> >
> > Now, why is bar.c still there? Why does the client fail to remove
> > the file?
>
> Update does this, I believe that's where we stand on file/dir removal.
Or, run 'svn rm -f', the --force flag. It will remove the file at the
time you schedule it for deletion.
>
> > % svn commit bar.c
> >
> > svn_error: #21050 : <Filesystem has no such file>
> > commit failed: wc locks and tmpfiles have been removed.
> >
> > svn_error: #21050 : <Filesystem has no such file>
> > commit failed: while sending tree-delta.
> >
> > svn_error: #21050 : <Filesystem has no such file>
> > file not found: filesystem `/tmp/subversion/repo/db', transaction
> > `2', path `/project/head/bar.c'
> >
> > Issue 565 seems kind of like this problem, but they are not exactly
> > the same. Is this a known problem or should I file a new issue?
>
> This is so known that the even The Onion is preparing a parody article
> of it. Don't bother with a new issue. It will be addressed in the
> new commit system.
Indeed, it's been filed forever. In fact, around here, we call it the
'add, commit, delete, commit' bug. It only exists in ra_local, and
know exactly why it happens.
For the next few weeks, just update after the first commit. It will
be fixed soon.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A couple of problems with svn rm.
Posted by Mo DeJong <su...@bayarea.net>.
On 22 Dec 2001 13:37:40 +0000
Philip Martin <ph...@codematters.co.uk> wrote:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > $ svn rm has-local-mods.c
> > ==> leaves has-local-mods.c, but schedules it for removal from
> > revision control
>
> Could we rename the working copy file, to has-local-mods.c.NNN say, so
> that the original name no longer exists in the working copy?
That could work, but what if we just do a diff and save the local mods
as a conflict? That way, the user will have to deal with the conflict before
doing the commit. If we create a conflict patch file, how would that interact
with the svn mv command? We could move the file in its unmodified state
and create a conflict patch file for the destination. I think the current code
moves the modified file so that the new file shows up in the M (modified) state.
I am not sure which is better, as long as the old file is removed I will be happy.
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A couple of problems with svn rm.
Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> $ svn rm has-local-mods.c
> ==> leaves has-local-mods.c, but schedules it for removal from
> revision control
Could we rename the working copy file, to has-local-mods.c.NNN say, so
that the original name no longer exists in the working copy?
This makes it easier to ensure that processes, like make, do not rely
on the name being present. Otherwise there is the risk of the process
working perfectly before the change is not committed, and then
breaking when the commit occurs.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A couple of problems with svn rm.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Hey Mo, Mike Pilato and I were just talking about your question
(below), and we agree with you that "svn rm" should remove the working
file when there are no local modifications. It's not like any
information is actually lost thereby, after all.
So we're proposing:
$ svn rm no-local-mods.c
==> removes no-local-mods.c, and schedules it for removal from
revision control
$ svn rm has-local-mods.c
==> leaves has-local-mods.c, but schedules it for removal from
revision control
$ svn rm --force any-file.c
==> removes any-file.c, and schedules it for removal from
revision control
Anyone think this is crazy?
-Karl and Mike
Mo DeJong <su...@bayarea.net> writes:
> > > % svn rm bar.c
> > > D bar.c
> > > % ls
> > > bar.c foo.c
> > >
> > > Now, why is bar.c still there? Why does the client fail to remove
> > > the file?
> >
> > Update does this, I believe that's where we stand on file/dir removal.
>
> Do you mean commit does the unlink? Why would the update
> command be responsible for this? What if I don't run update? If I delete
> a bunch of files and then commit the delete, I would not expect the files
> to still be there. Is this same logic going to apply to a `svn mv` operation?
> I would not want to `svn mv` a file and have to run update before the old
> one went away. Can't we just let rm remove the file in the wc? I could
> see where we might not want to do that if there were modifications to
> the file, but in the normal case this seems strange. Ben mentioned the
> --force flag, why is that not the default for a rm operation?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A couple of problems with svn rm.
Posted by Mo DeJong <su...@bayarea.net>.
On 07 Dec 2001 12:40:38 -0600
cmpilato@collab.net wrote:
> Mo DeJong <su...@bayarea.net> writes:
>
> > % svn rm bar.c
> > D bar.c
> > % ls
> > bar.c foo.c
> >
> > Now, why is bar.c still there? Why does the client fail to remove
> > the file?
>
> Update does this, I believe that's where we stand on file/dir removal.
Do you mean commit does the unlink? Why would the update
command be responsible for this? What if I don't run update? If I delete
a bunch of files and then commit the delete, I would not expect the files
to still be there. Is this same logic going to apply to a `svn mv` operation?
I would not want to `svn mv` a file and have to run update before the old
one went away. Can't we just let rm remove the file in the wc? I could
see where we might not want to do that if there were modifications to
the file, but in the normal case this seems strange. Ben mentioned the
--force flag, why is that not the default for a rm operation?
> > % svn commit bar.c
> >
> > svn_error: #21050 : <Filesystem has no such file>
> > commit failed: wc locks and tmpfiles have been removed.
> >
> > svn_error: #21050 : <Filesystem has no such file>
> > commit failed: while sending tree-delta.
> >
> > svn_error: #21050 : <Filesystem has no such file>
> > file not found: filesystem `/tmp/subversion/repo/db', transaction
> > `2', path `/project/head/bar.c'
> >
> > Issue 565 seems kind of like this problem, but they are not exactly
> > the same. Is this a known problem or should I file a new issue?
>
> This is so known that the even The Onion is preparing a parody article
> of it. Don't bother with a new issue. It will be addressed in the
> new commit system.
Humm, sounds like there needs to be a test case for this. How about adding
the following to basic_tests.py? I think it is correct, but I am not sure since
the second commit crashes with the above error.
cheers
Mo
#----------------------------------------------------------------------
def basic_delete():
"basic delete command"
sbox = "basic_delete"
wc_dir = os.path.join (svntest.main.general_wc_dir, sbox)
if svntest.actions.make_repo_and_wc(sbox):
return 1
# Add new file and commit it
foo_path = os.path.join(wc_dir, 'foo.c')
svntest.main.file_append (foo_path, 'foo data')
svntest.main.run_svn(None, 'add', foo_path)
# Created expected output tree for 'svn commit'
output_list = [ [foo_path, None, {}, {'verb' : 'Adding' }] ]
expected_output_tree = svntest.tree.build_generic_tree(output_list)
# Create expected status tree for 'svn commit'
status_list = svntest.actions.get_virginal_status_list(wc_dir, '2')
# FIXME: Why can't we pass both wc and repo revisions to above func?
for item in status_list:
item[3]['wc_rev'] = '1'
item = [foo_path, None, {},
{'status' : '_ ',
'wc_rev' : '2',
'repos_rev' : '2'}]
status_list.append(item)
expected_status_tree = svntest.tree.build_generic_tree(status_list)
if svntest.actions.run_and_verify_commit (wc_dir,
expected_output_tree,
expected_status_tree,
None,
None, None,
None, None,
wc_dir):
return 1;
# Now remove the newely added file and run 'svn commit'
svntest.main.run_svn(None, 'delete', foo_path)
# Created expected output tree for 'svn commit'
output_list = [ [foo_path, None, {}, {'verb' : 'Deleting' }] ]
expected_output_tree = svntest.tree.build_generic_tree(output_list)
# Foo should now be deleted and head revision should be 3
status_list = svntest.actions.get_virginal_status_list(wc_dir, '3')
# FIXME: Why can't we pass both wc and repo revisions to above func?
for item in status_list:
item[3]['wc_rev'] = '1'
return svntest.actions.run_and_verify_commit (wc_dir,
expected_output_tree,
expected_status_tree,
None,
None, None,
None, None,
wc_dir)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A couple of problems with svn rm.
Posted by cm...@collab.net.
Mo DeJong <su...@bayarea.net> writes:
> % svn rm bar.c
> D bar.c
> % ls
> bar.c foo.c
>
> Now, why is bar.c still there? Why does the client fail to remove
> the file?
Update does this, I believe that's where we stand on file/dir removal.
> % svn commit bar.c
>
> svn_error: #21050 : <Filesystem has no such file>
> commit failed: wc locks and tmpfiles have been removed.
>
> svn_error: #21050 : <Filesystem has no such file>
> commit failed: while sending tree-delta.
>
> svn_error: #21050 : <Filesystem has no such file>
> file not found: filesystem `/tmp/subversion/repo/db', transaction
> `2', path `/project/head/bar.c'
>
> Issue 565 seems kind of like this problem, but they are not exactly
> the same. Is this a known problem or should I file a new issue?
This is so known that the even The Onion is preparing a parody article
of it. Don't bother with a new issue. It will be addressed in the
new commit system.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org