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/09/17 08:23:11 UTC
The unadd, undelete methods and the client README.
Hi all.
I have been looking at the README file in subversion/clients/cmdline
and the man files in doc/user/manual and it seems things are a bit
out of date.
One of the things I found in svn-manual.html was the "unadd" and "undelete"
subcommands for the svn client. There was no mention of these commands
in the README. Should the client README be retired? It seems to describe
lots of features that do not exist. It also describes other features that do not
yet exist. Would it be better to move this into a new texi file in the
doc/user/manual directory? I would be willing to do that work if it seems
like a good idea.
My second question is related to the "unadd" and "undelete" methods included
in the svn client. Why do we need a special unadd method to undo an add?
Can't the user just call delete on the file or dir?
Testing on the current impl shows that delete will "unadd" an added file.
Both delete and unadd fail on an added directory so I am not sure what
is going on there. Does anyone know why these un* methods are in the client?
Can't we just remove the user visible subcommands and call the svn_client_unadd
method when delete is invoked for an added but not yet commited dir (and
vice versa) ?
% svn add foo.c
% svn status foo.c
A 0 ( 110) foo.c
% svn delete foo.c
D foo.c
% mkdir foo
% svn add foo
% svn unadd foo
svn_error: #21026 : <Can't find an entry>
No default entry in directory `foo'
% svn delete foo
svn_error: #21026 : <Can't find an entry>
No default entry in directory `foo'
The CVS log indicates that these methods were added in May by cmpilato.
Could you help shed some light on this?
thanks
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by Philip Martin <ph...@ntlworld.com>.
Greg Stein <gs...@lyra.org> writes:
> Merge? That doesn't make sense. You aren't merging anything... you're
> getting an old revision and bringing it back somewhere in the repository.
> That is the "copy" operation.
>
> $ svn copy -r 5 foo.c restored-foo.c
>
I may (usually?) want it to come back with the same name.
The merge command is all about apply deltas, and I would expect the
merge command to be able to reverse deltas and then apply them (for
removing changes made further back in the version history). Is the
deletion delta special? It certainly could be special, but does it
need to be?
Rational's ClearCase uses merge to revert deletions. Their model is a
bit different, the directory *containing* the elements is checked out
when deleting elements. Something like:
$ cleartool co .
$ cleartool rm foo.c
$ cleartool ci .
Adding new files is similar:
$ cleartool co .
$ cleartool mkelem bar.c
$ cleartool ci .
$ cleartool ci bar.c # new elements are usually created checked-out
Now if deleting foo.c produced version N of the directory, and adding
bar.c produced version N+1, I reinstate foo.c using merge (don't
remember the exact syntax, but something like)
$ cleartool co .
$ cleartool merge -to . --version main/N --reverse
$ cleartool ci .
This will produce version N+2, which contains both foo.c and
bar.c. foo.c will have the the exact same version history that it had
before it was deleted, it is the same element.
In the ClearCase model merge is the only sensible way to revert
deletions since deletion operates on the containing directory rather
than the element. Subversion may of course be different.
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 17, 2001 at 03:26:48PM -0500, cmpilato@collab.net wrote:
> Mo DeJong <su...@bayarea.net> writes:
>...
> > That certainly sounds like something revert should do. That would
> > provide the current undelete functionality but it would not give us
> > the ability to do a `snv undelete dir` on a directory delete that
> > has already been committed.
>
> Dude, that deleted dir is in revision history. Now, I don't know how
> easy/hard it would be resurrect that directory *and preserve its
> versioned history*, but simply recreating it is a one-line shell
> command (up'ing to an old version, stripping SVN/ subdirs, add
> --recursing that bad boy, and committing). And I think I just saw
> someone mail about `svn merge', which is certainly the way to go with
> this.
Merge? That doesn't make sense. You aren't merging anything... you're
getting an old revision and bringing it back somewhere in the repository.
That is the "copy" operation.
$ svn copy -r 5 foo.c restored-foo.c
That would copy revision 5 of foo.c into the current WC as restored-foo.c.
Of course, if foo.c was deleted in some later revision, you could copy back
into the WC as foo.c to restore it.
Using the copy command ensures you have the right history, too. And note
that it can call back anything, from anywhere.
> If `revert' got smarter and `unadd' and `undelete' could die, I
> wouldn't lose a wink of sleep over that change. :-)
+1 on using revert rather than unadd/undelete.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by Mo DeJong <su...@bayarea.net>.
On 17 Sep 2001 15:26:48 -0500
cmpilato@collab.net wrote:
> Mo DeJong <su...@bayarea.net> writes:
> > That certainly sounds like something revert should do. That wou
> > provide the current undelete functionality but it would not give us
> > the ability to do a `snv undelete dir` on a directory delete that
> > has already been committed.
>
> Dude, that deleted dir is in revision history. Now, I don't know how
> easy/hard it would be resurrect that directory *and preserve its
> versioned history*, but simply recreating it is a one-line shell
> command (up'ing to an old version, stripping SVN/ subdirs, add
> --recursing that bad boy, and committing). And I think I just saw
> someone mail about `svn merge', which is certainly the way to go with
> this.
>
> If `revert' got smarter and `unadd' and `undelete' could die, I
> wouldn't lose a wink of sleep over that change. :-)
Well, both you and Philip blew a hole in my only argument for
keeping the undelete command. On that note, here is a patch
that removes all traces of those two commands. I am going to
attach and paste this patch just in case something goes wrong
since it is quite large.
cheers
Mo DeJong
2001-09-17 Mo DeJong <su...@bayarea.net>
Remove useless unadd and undelete subcomands.
* subversion/include/svn_wc.h (svn_wc_unadd, svn_wc_undelete):
* subversion/include/svn_client.h (svn_client_unadd, svn_client_undelete):
* subversion/include/svn_pools.h (report_unadded_item,
report_undeleted_item):
* subversion/libsvn_wc/entries.c:
* subversion/libsvn_wc/adm_ops.c (mark_tree_state,
svn_wc_unadd, svn_wc_undelete):
* subversion/libsvn_subr/svn_error.c (report_unadded_item,
report_undeleted_item):
* subversion/libsvn_client/delete.c (svn_client_undelete):
* subversion/libsvn_client/add.c (svn_client_unadd):
* subversion/bindings/java/jni/org/tigris/subversion/lib/WorkingCopy.java:
* subversion/bindings/java/jni/org/tigris/subversion/lib/Client.java:
* subversion/clients/cmdline/cl.h (svn_cl__unadd, svn_cl__undelete):
* subversion/clients/cmdline/add-cmd.c (svn_cl__unadd):
* subversion/clients/cmdline/delete-cmd.c (svn_cl__undelete):
* subversion/clients/cmdline/feedback.c (report_unadded_item,
report_undeleted_item):
* subversion/clients/cmdline/main.c (unadd, undelete):
* subversion/tests/clients/cmdline/schedule_tests.py:
* doc/user/svn_for_cvs_users.txt:
* doc/user/manual/adds.texi:
Index: ./subversion/include/svn_wc.h
===================================================================
--- ./subversion/include/SVN/text-base/svn_wc.h Mon Sep 17 10:42:14 2001
+++ ./subversion/include/svn_wc.h Mon Sep 17 17:45:08 2001
@@ -114,8 +114,6 @@
svn_wc_schedule_add, /* Slated for addition */
svn_wc_schedule_delete, /* Slated for deletion */
svn_wc_schedule_replace, /* Slated for replacement (delete + add) */
- svn_wc_schedule_unadd, /* Slated for un-addition */
- svn_wc_schedule_undelete /* Slated for un-deletion */
};
enum svn_wc_existence_t
@@ -341,19 +339,6 @@
caller should take care of that, if it cares. */
svn_error_t *svn_wc_add_file (svn_stringbuf_t *file,
apr_pool_t *pool);
-
-/* Recursively un-mark a tree (beginning at a directory or a file
- PATH) for addition. */
-svn_error_t *svn_wc_unadd (svn_stringbuf_t *path,
- apr_pool_t *pool);
-
-/* Un-mark a PATH for deletion. If RECURSE is TRUE and PATH
- represents a directory, un-mark the entire tree under PATH for
- deletion. */
-svn_error_t *svn_wc_undelete (svn_stringbuf_t *path,
- svn_boolean_t recurse,
- apr_pool_t *pool);
-
/* Remove entry NAME in PATH from revision control. NAME must be
either a file or SVN_WC_ENTRY_THIS_DIR.
Index: ./subversion/include/svn_client.h
===================================================================
--- ./subversion/include/SVN/text-base/svn_client.h Mon Sep 10 09:52:05 2001
+++ ./subversion/include/svn_client.h Mon Sep 17 17:43:02 2001
@@ -247,22 +247,10 @@
svn_boolean_t recursive,
apr_pool_t *pool);
-
-svn_error_t *
-svn_client_unadd (svn_stringbuf_t *path,
- apr_pool_t *pool);
-
-
svn_error_t *
svn_client_delete (svn_stringbuf_t *path,
svn_boolean_t force,
apr_pool_t *pool);
-
-
-svn_error_t *
-svn_client_undelete (svn_stringbuf_t *path,
- svn_boolean_t recursive,
- apr_pool_t *pool);
/* Import a tree, using optional pre- and post-commit hook editors
* (BEFORE_EDITOR, BEFORE_EDIT_BATON / AFTER_EDITOR,
Index: ./subversion/include/svn_pools.h
===================================================================
--- ./subversion/include/SVN/text-base/svn_pools.h Mon Sep 10 09:52:03 2001
+++ ./subversion/include/svn_pools.h Mon Sep 17 17:36:00 2001
@@ -115,14 +115,8 @@
/* Report items just scheduled for addition to revision control. */
apr_status_t (*report_added_item) (const char *path, apr_pool_t *pool);
- /* Report items just un-scheduled for addition to revision control. */
- apr_status_t (*report_unadded_item) (const char *path, apr_pool_t *pool);
-
/* Report items just scheduled for removal to revision control. */
apr_status_t (*report_deleted_item) (const char *path, apr_pool_t *pool);
-
- /* Report items just un-scheduled for removal to revision control. */
- apr_status_t (*report_undeleted_item) (const char *path, apr_pool_t *pool);
/* Generic human-readable we-think-it's-non-fatal warning. This
function can parse STATUS and decide whether a "real" error
Index: ./subversion/libsvn_wc/entries.c
===================================================================
--- ./subversion/libsvn_wc/SVN/text-base/entries.c Mon Sep 10 17:16:48 2001
+++ ./subversion/libsvn_wc/entries.c Mon Sep 17 18:10:20 2001
@@ -762,10 +762,8 @@
/* These are all valid states */
break;
- case svn_wc_schedule_unadd:
- case svn_wc_schedule_undelete:
default:
- /* These are all INvalid states */
+ /* This is an invalid state */
return svn_error_createf
(SVN_ERR_WC_CORRUPT, 0, NULL, pool,
"Directory '%s' has an invalid schedule",
@@ -798,10 +796,8 @@
/* These are all valid states */
break;
- case svn_wc_schedule_unadd:
- case svn_wc_schedule_undelete:
default:
- /* These are all INvalid states */
+ /* This is an invalid state */
return svn_error_createf
(SVN_ERR_WC_CORRUPT, 0, NULL, pool,
"'%s' in directory '%s' has an invalid schedule",
@@ -1240,13 +1236,6 @@
"fold_state_changes: Can't replace '%s' in deleted directory"
"--try undeleting its parent directory first",
name->data);
- if (*schedule == svn_wc_schedule_undelete)
- return
- svn_error_createf
- (SVN_ERR_WC_ENTRY_BOGUS_MERGE, 0, NULL, pool,
- "fold_state_changes: Can't undelete '%s' in deleted directory"
- "--try undeleting its parent directory first",
- name->data);
}
switch (entry->schedule)
@@ -1255,11 +1244,8 @@
switch (*schedule)
{
case svn_wc_schedule_normal:
- case svn_wc_schedule_unadd:
- case svn_wc_schedule_undelete:
- /* There are all no-op cases. _normal is trivial, _unadd
- and _undelete might merit a warning, but whatever. Reset
- the schedule modification bit and move along. */
+ /* Normal is a trivial no-op case. Reset the
+ schedule modification bit and move along. */
*modify_flags &= ~SVN_WC__ENTRY_MODIFY_SCHEDULE;
return SVN_NO_ERROR;
@@ -1289,22 +1275,18 @@
case svn_wc_schedule_normal:
case svn_wc_schedule_add:
case svn_wc_schedule_replace:
- case svn_wc_schedule_undelete:
/* These are all no-op cases. Normal is obvious, as is add.
Replace on an entry marked for addition breaks down to
(add + (delete + add)), which resolves to just (add), and
since this entry is already marked with (add), this too
- is a no-op. Undelete might merit a warning about
- undeleting stuff that isn't deleted, but we opt not to
- care. */
+ is a no-op. */
*modify_flags &= ~SVN_WC__ENTRY_MODIFY_SCHEDULE;
return SVN_NO_ERROR;
case svn_wc_schedule_delete:
- case svn_wc_schedule_unadd:
- /* Not-yet-versioned item being deleted or un-added? Just
- remove the entry altogether. */
+ /* Not-yet-versioned item being deleted, Just
+ remove the entry. */
apr_hash_set (entries, name->data, name->len, NULL);
return SVN_NO_ERROR;
}
@@ -1315,7 +1297,6 @@
{
case svn_wc_schedule_normal:
case svn_wc_schedule_delete:
- case svn_wc_schedule_unadd:
/* These are no-op cases. */
*modify_flags &= ~SVN_WC__ENTRY_MODIFY_SCHEDULE;
return SVN_NO_ERROR;
@@ -1333,13 +1314,7 @@
(delete + (delete + add)), which might deserve a warning,
but whatever. */
return SVN_NO_ERROR;
-
- case svn_wc_schedule_undelete:
- /* Undeleting a to-be-deleted entry resets the schedule to
- 'normal'. */
- *schedule = svn_wc_schedule_normal;
- return SVN_NO_ERROR;
}
break;
@@ -1364,23 +1339,9 @@
case svn_wc_schedule_delete:
/* Deleting a to-be-replaced entry breaks down to ((delete +
add) + delete) which resolves to a flat deletion. */
- case svn_wc_schedule_unadd:
- /* Unadding a to-be-replaced entry breaks down to ((delete +
- add) - add), which leaves just the deletion. */
*schedule = svn_wc_schedule_delete;
return SVN_NO_ERROR;
-
- case svn_wc_schedule_undelete:
- /* Despite the fact that the to-be-replaced state of this
- entry implies a deletion action, that's buried under an
- addition action. */
- return
- svn_error_createf
- (SVN_ERR_WC_ENTRY_BOGUS_MERGE, 0, NULL, pool,
- "fold_state_changes: Can't undelete '%s' marked for replacement"
- "--try unadding this entry first",
- name->data);
}
break;
Index: ./subversion/libsvn_wc/adm_ops.c
===================================================================
--- ./subversion/libsvn_wc/SVN/text-base/adm_ops.c Mon Sep 10 17:16:48 2001
+++ ./subversion/libsvn_wc/adm_ops.c Mon Sep 17 17:49:31 2001
@@ -356,8 +356,6 @@
enum mark_tree_state {
mark_tree_state_delete = 1,
- mark_tree_state_unadd,
- mark_tree_state_undelete
};
@@ -374,17 +372,6 @@
/* Read the entries file for this directory. */
SVN_ERR (svn_wc_entries_read (&entries, dir, pool));
- /* Handle "this dir" for cases that need it handled before
- recursion. */
- if (state == mark_tree_state_undelete)
- SVN_ERR (svn_wc__entry_modify
- (dir, NULL,
- SVN_WC__ENTRY_MODIFY_SCHEDULE,
- SVN_INVALID_REVNUM, svn_node_dir,
- svn_wc_schedule_undelete,
- svn_wc_existence_normal,
- FALSE, 0, 0, NULL, pool, NULL));
-
/* Mark each entry in the entries file. */
for (hi = apr_hash_first (pool, entries); hi; hi = apr_hash_next (hi))
{
@@ -436,45 +423,6 @@
}
break;
- case mark_tree_state_unadd:
- SVN_ERR (svn_wc__entry_modify
- (dir, basename,
- SVN_WC__ENTRY_MODIFY_SCHEDULE,
- SVN_INVALID_REVNUM, entry->kind,
- svn_wc_schedule_unadd,
- svn_wc_existence_normal,
- FALSE, 0, 0, NULL, subpool, NULL));
- if (fbtable)
- {
- apr_status_t apr_err;
-
- apr_err = fbtable->report_unadded_item (fullpath->data, pool);
- if (apr_err)
- return svn_error_createf
- (apr_err, 0, NULL, pool,
- "Error reporting unadded item `%s'", fullpath->data);
- }
- break;
-
- case mark_tree_state_undelete:
- SVN_ERR (svn_wc__entry_modify
- (dir, basename,
- SVN_WC__ENTRY_MODIFY_SCHEDULE,
- SVN_INVALID_REVNUM, entry->kind,
- svn_wc_schedule_undelete,
- svn_wc_existence_normal,
- FALSE, 0, 0, NULL, subpool, NULL));
- if (fbtable)
- {
- apr_status_t apr_err;
-
- apr_err = fbtable->report_undeleted_item (fullpath->data, pool);
- if (apr_err)
- return svn_error_createf
- (apr_err, 0, NULL, pool,
- "Error reporting undeleted item `%s'", fullpath->data);
- }
- break;
}
/* Reset FULLPATH to just hold this dir's name. */
@@ -493,14 +441,6 @@
svn_wc_schedule_delete,
svn_wc_existence_normal,
FALSE, 0, 0, NULL, pool, NULL));
- if (state == mark_tree_state_unadd)
- SVN_ERR (svn_wc__entry_modify
- (dir, NULL,
- SVN_WC__ENTRY_MODIFY_SCHEDULE,
- SVN_INVALID_REVNUM, svn_node_dir,
- svn_wc_schedule_unadd,
- svn_wc_existence_normal,
- FALSE, 0, 0, NULL, pool, NULL));
/* Destroy our per-iteration pool. */
svn_pool_destroy (subpool);
@@ -715,132 +668,6 @@
svn_error_t *
-svn_wc_unadd (svn_stringbuf_t *path,
- apr_pool_t *pool)
-{
- svn_wc_entry_t *entry;
- svn_stringbuf_t *dir, *basename;
-
- /* Get the entry for PATH */
- SVN_ERR (svn_wc_entry (&entry, path, pool));
- if (! entry)
- return svn_error_createf
- (SVN_ERR_WC_ENTRY_NOT_FOUND, 0, NULL, pool,
- "'%s' does not appear to be under revision control", path->data);
-
- if (entry->kind == svn_node_dir)
- {
- /* Recursively un-mark a whole tree for addition. */
- SVN_ERR (mark_tree (path, mark_tree_state_unadd, pool));
- }
-
- /* We need to un-mark this entry for addition in its parent's entries
- file, so we split off basename from the parent path, then fold in
- the addition of a delete flag. */
- svn_path_split (path, &dir, &basename, svn_path_local_style, pool);
- if (svn_path_is_empty (dir, svn_path_local_style))
- svn_stringbuf_set (dir, ".");
-
- SVN_ERR (svn_wc__entry_modify
- (dir, basename,
- SVN_WC__ENTRY_MODIFY_SCHEDULE,
- SVN_INVALID_REVNUM, svn_node_none,
- svn_wc_schedule_unadd,
- svn_wc_existence_normal,
- FALSE, 0, 0, NULL, pool, NULL));
-
- /* Now, call our client feedback function. */
- {
- svn_pool_feedback_t *fbtable = svn_pool_get_feedback_vtable (pool);
- if (fbtable)
- {
- apr_status_t apr_err;
-
- apr_err = fbtable->report_unadded_item (path->data, pool);
- if (apr_err)
- return svn_error_createf
- (apr_err, 0, NULL, pool,
- "Error reporting un-added item `%s'", path->data);
- }
- }
-
- return SVN_NO_ERROR;
-}
-
-
-/* Un-mark a PATH for deletion. If RECURSE is TRUE and PATH
- represents a directory, un-mark the entire tree under PATH for
- deletion. */
-svn_error_t *
-svn_wc_undelete (svn_stringbuf_t *path,
- svn_boolean_t recursive,
- apr_pool_t *pool)
-{
- svn_wc_entry_t *entry;
- svn_stringbuf_t *dir, *basename;
-
- /* Get the entry for PATH */
- SVN_ERR (svn_wc_entry (&entry, path, pool));
- if (! entry)
- return svn_error_createf
- (SVN_ERR_WC_ENTRY_NOT_FOUND, 0, NULL, pool,
- "'%s' does not appear to be under revision control", path->data);
-
- if (entry->kind == svn_node_dir)
- {
- if (recursive)
- {
- /* Recursively un-mark a whole tree for deletion. */
- SVN_ERR (mark_tree (path, mark_tree_state_undelete, pool));
- }
- else
- {
- /* Just mark the "this dir" entry for this directory. */
- SVN_ERR (svn_wc__entry_modify
- (path, NULL,
- SVN_WC__ENTRY_MODIFY_SCHEDULE,
- SVN_INVALID_REVNUM, svn_node_none,
- svn_wc_schedule_undelete,
- svn_wc_existence_normal,
- FALSE, 0, 0, NULL, pool, NULL));
- }
- }
-
- /* We need to un-mark this entry for deletion in its parent's entries
- file, so we split off basename from the parent path, then fold in
- the addition of a delete flag. */
- svn_path_split (path, &dir, &basename, svn_path_local_style, pool);
- if (svn_path_is_empty (dir, svn_path_local_style))
- svn_stringbuf_set (dir, ".");
-
- SVN_ERR (svn_wc__entry_modify
- (dir, basename,
- SVN_WC__ENTRY_MODIFY_SCHEDULE,
- SVN_INVALID_REVNUM, svn_node_none,
- svn_wc_schedule_undelete,
- svn_wc_existence_normal,
- FALSE, 0, 0, NULL, pool, NULL));
-
- /* Now, call our client feedback function. */
- {
- svn_pool_feedback_t *fbtable = svn_pool_get_feedback_vtable (pool);
- if (fbtable)
- {
- apr_status_t apr_err;
-
- apr_err = fbtable->report_undeleted_item (path->data, pool);
- if (apr_err)
- return svn_error_createf
- (apr_err, 0, NULL, pool,
- "Error reporting un-deleted item `%s'", path->data);
- }
- }
-
- return SVN_NO_ERROR;
-}
-
-
-svn_error_t *
svn_wc_revert (svn_stringbuf_t *path,
apr_pool_t *pool)
{
Index: ./subversion/libsvn_subr/svn_error.c
===================================================================
--- ./subversion/libsvn_subr/SVN/text-base/svn_error.c Mon Sep 10 09:51:41 2001
+++ ./subversion/libsvn_subr/svn_error.c Mon Sep 17 17:51:54 2001
@@ -200,24 +200,12 @@
}
static apr_status_t
-report_unadded_item (const char *path, apr_pool_t *pool)
-{
- return APR_SUCCESS;
-}
-
-static apr_status_t
report_deleted_item (const char *path, apr_pool_t *pool)
{
return APR_SUCCESS;
}
static apr_status_t
-report_undeleted_item (const char *path, apr_pool_t *pool)
-{
- return APR_SUCCESS;
-}
-
-static apr_status_t
report_warning (apr_status_t status, const char *warning)
{
return APR_SUCCESS;
@@ -269,9 +257,7 @@
/* Stuff it with default useless functions. */
feedback_vtable->report_unversioned_item = report_unversioned_item;
feedback_vtable->report_added_item = report_added_item;
- feedback_vtable->report_unadded_item = report_unadded_item;
feedback_vtable->report_deleted_item = report_deleted_item;
- feedback_vtable->report_undeleted_item = report_undeleted_item;
feedback_vtable->report_warning = report_warning;
feedback_vtable->report_progress = report_progress;
Index: ./subversion/libsvn_client/delete.c
===================================================================
--- ./subversion/libsvn_client/SVN/text-base/delete.c Mon Sep 10 09:51:33 2001
+++ ./subversion/libsvn_client/delete.c Mon Sep 17 17:44:02 2001
@@ -61,22 +61,6 @@
return SVN_NO_ERROR;
}
-
-svn_error_t *
-svn_client_undelete (svn_stringbuf_t *path,
- svn_boolean_t recursive,
- apr_pool_t *pool)
-{
- svn_error_t *err;
-
- /* Mark the entry for deletion. */
- err = svn_wc_undelete (path, recursive, pool);
- if (err)
- return err;
-
- return SVN_NO_ERROR;
-}
-
/*
* local variables:
Index: ./subversion/libsvn_client/add.c
===================================================================
--- ./subversion/libsvn_client/SVN/text-base/add.c Mon Sep 10 09:51:32 2001
+++ ./subversion/libsvn_client/add.c Mon Sep 17 17:43:15 2001
@@ -146,21 +146,6 @@
return SVN_NO_ERROR;
}
-
-svn_error_t *
-svn_client_unadd (svn_stringbuf_t *path,
- apr_pool_t *pool)
-{
- svn_error_t *err;
-
- err = svn_wc_unadd (path, pool);
- if (err)
- return err;
-
- return SVN_NO_ERROR;
-}
-
-
/*
* local variables:
Index: ./subversion/bindings/java/jni/org/tigris/subversion/lib/WorkingCopy.java
===================================================================
--- ./subversion/bindings/java/jni/org/tigris/subversion/lib/SVN/text-base/WorkingCopy.java Mon Sep 10 09:51:27 2001
+++ ./subversion/bindings/java/jni/org/tigris/subversion/lib/WorkingCopy.java Mon Sep 17 17:32:18 2001
@@ -133,21 +133,6 @@
public void addFile(String file) throws SubversionException;
/**
- * Recursively un-mark a tree (beginning at a directory or a file
- * PATH) for addition.
- */
- public void unadd(String path) throws SubversionException;
-
- /**
- * Un-mark a PATH for deletion. If RECURSE is TRUE and PATH
- * represents a directory, un-mark the entire tree under PATH for
- * deletion.
- */
- public void undelete(String path, boolean recurse)
- throws SubversionException;
-
-
- /**
* Remove entry NAME in PATH from revision control. NAME must be
* either a file or SVN_WC_ENTRY_THIS_DIR.
*
Index: ./subversion/bindings/java/jni/org/tigris/subversion/lib/Client.java
===================================================================
--- ./subversion/bindings/java/jni/org/tigris/subversion/lib/SVN/text-base/Client.java Mon Sep 10 09:51:29 2001
+++ ./subversion/bindings/java/jni/org/tigris/subversion/lib/Client.java Mon Sep 17 17:33:34 2001
@@ -85,12 +85,7 @@
public void add(String path, boolean recursive) throws SubversionException;
- public void unAdd(String path) throws SubversionException;
-
public void delete(String path, boolean force) throws SubversionException;
-
- public void unDelete(String path, boolean recursive)
- throws SubversionException;
/**
* Import a tree, using optional pre- and post-commit hook editors
Index: ./subversion/clients/cmdline/cl.h
===================================================================
--- subversion/clients/cmdline/SVN/text-base/cl.h Wed Sep 12 23:02:28 2001
+++ subversion/clients/cmdline/cl.h Mon Sep 17 17:31:04 2001
@@ -122 +130,0 @@
- svn_cl__unadd,
@@ -127 +134,0 @@
- svn_cl__undelete,
Index: ./subversion/clients/cmdline/add-cmd.c
===================================================================
--- ./subversion/clients/cmdline/SVN/text-base/add-cmd.c Mon Sep 10 09:51:10 2001
+++ ./subversion/clients/cmdline/add-cmd.c Mon Sep 17 17:31:04 2001
@@ -1,5 +1,5 @@
/*
- * add-cmd.c -- Subversion add/unadd commands
+ * add-cmd.c -- Add command
*
* ====================================================================
* Copyright (c) 2000-2001 CollabNet. All rights reserved.
@@ -67,33 +67,6 @@
return SVN_NO_ERROR;
}
-
-
-svn_error_t *
-svn_cl__unadd (apr_getopt_t *os,
- svn_cl__opt_state_t *opt_state,
- apr_pool_t *pool)
-{
- apr_array_header_t *targets;
- int i;
-
- targets = svn_cl__args_to_target_array (os, pool);
-
- if (targets->nelts)
- for (i = 0; i < targets->nelts; i++)
- {
- svn_stringbuf_t *target = ((svn_stringbuf_t **) (targets->elts))[i];
- SVN_ERR (svn_client_unadd (target, pool));
- }
- else
- {
- svn_cl__subcommand_help ("unadd", pool);
- return svn_error_create (SVN_ERR_CL_ARG_PARSING_ERROR, 0, 0, pool, "");
- }
-
- return SVN_NO_ERROR;
-}
-
/*
Index: ./subversion/clients/cmdline/delete-cmd.c
===================================================================
--- ./subversion/clients/cmdline/SVN/text-base/delete-cmd.c Mon Sep 10 09:51:10 2001
+++ ./subversion/clients/cmdline/delete-cmd.c Mon Sep 17 17:31:04 2001
@@ -1,5 +1,5 @@
/*
- * delete-cmd.c -- Delete/undelete commands
+ * delete-cmd.c -- Delete command
*
* ====================================================================
* Copyright (c) 2000-2001 CollabNet. All rights reserved.
@@ -56,36 +56,6 @@
else
{
svn_cl__subcommand_help ("delete", pool);
- return svn_error_create (SVN_ERR_CL_ARG_PARSING_ERROR, 0, 0, pool, "");
- }
-
- return SVN_NO_ERROR;
-}
-
-
-svn_error_t *
-svn_cl__undelete (apr_getopt_t *os,
- svn_cl__opt_state_t *opt_state,
- apr_pool_t *pool)
-{
- svn_error_t *err;
- apr_array_header_t *targets;
- int i;
- svn_boolean_t recursive = opt_state->recursive;
-
- targets = svn_cl__args_to_target_array (os, pool);
-
- if (targets->nelts)
- for (i = 0; i < targets->nelts; i++)
- {
- svn_stringbuf_t *target = ((svn_stringbuf_t **) (targets->elts))[i];
- err = svn_client_undelete (target, recursive, pool);
- if (err)
- return err;
- }
- else
- {
- svn_cl__subcommand_help ("undelete", pool);
return svn_error_create (SVN_ERR_CL_ARG_PARSING_ERROR, 0, 0, pool, "");
}
Index: ./subversion/clients/cmdline/feedback.c
===================================================================
--- ./subversion/clients/cmdline/SVN/text-base/feedback.c Mon Sep 10 09:51:11 2001
+++ ./subversion/clients/cmdline/feedback.c Mon Sep 17 17:44:36 2001
@@ -78,16 +78,6 @@
return APR_SUCCESS;
}
-
-static apr_status_t
-report_unadded_item (const char *path, apr_pool_t *pool)
-{
- printf ("- %s\n", path);
-
- return APR_SUCCESS;
-}
-
-
static apr_status_t
report_deleted_item (const char *path, apr_pool_t *pool)
{
@@ -96,16 +86,6 @@
return APR_SUCCESS;
}
-
-static apr_status_t
-report_undeleted_item (const char *path, apr_pool_t *pool)
-{
- printf ("+ %s\n", path);
-
- return APR_SUCCESS;
-}
-
-
static apr_status_t
report_warning (apr_status_t status, const char *warning)
{
@@ -137,9 +117,7 @@
feedback_vtable->report_unversioned_item = report_unversioned_item;
feedback_vtable->report_added_item = report_added_item;
- feedback_vtable->report_unadded_item = report_unadded_item;
feedback_vtable->report_deleted_item = report_deleted_item;
- feedback_vtable->report_undeleted_item = report_undeleted_item;
feedback_vtable->report_warning = report_warning;
/* we're -not- overriding report_progress; we have no need for it
yet. */
Index: ./subversion/clients/cmdline/main.c
===================================================================
--- ./subversion/clients/cmdline/SVN/text-base/main.c Wed Sep 12 23:02:57 2001
+++ ./subversion/clients/cmdline/main.c Mon Sep 17 17:31:04 2001
@@ -64,11 +64,6 @@
{ "ad", TRUE, NULL, NULL },
{ "new", TRUE, NULL, NULL },
- { "unadd", FALSE, svn_cl__unadd,
- "Recursively un-add files and directories marked for addition.\n"
- "usage: unadd [TARGETS]\n" },
- { "unad", TRUE, NULL, NULL },
-
{ "checkout", FALSE, svn_cl__checkout,
"Check out a working directory from a repository.\n"
"usage: checkout REPOSPATH1 [REPOSPATH2 REPOSPATH3...]\n" },
@@ -86,12 +81,6 @@
{ "remove", TRUE, NULL, NULL },
{ "rm", TRUE, NULL, NULL },
- { "undelete", FALSE, svn_cl__undelete,
- "Undelete files and directories marked for deletion.\n"
- "usage: undelete [TARGETS]\n" },
- { "undel", TRUE, NULL, NULL },
- { "unrm", TRUE, NULL, NULL },
-
{ "help", FALSE, svn_cl__help,
"Display this usage message.\n"
"usage: help [SUBCOMMAND1 [SUBCOMMAND2] ...]\n" },
Index: ./subversion/tests/clients/cmdline/schedule_tests.py
===================================================================
--- ./subversion/tests/clients/cmdline/SVN/text-base/schedule_tests.py Mon Sep 10 09:50:26 2001
+++ ./subversion/tests/clients/cmdline/schedule_tests.py Mon Sep 17 17:51:35 2001
@@ -1,7 +1,7 @@
#!/usr/bin/env python
#
# schedule_tests.py: testing working copy scheduling
-# (adds, unadds, deletes, and undeletes)
+# (adds, and deletes)
#
# Subversion is a tool for revision control.
# See http://subversion.tigris.org for more information.
Index: ./doc/user/svn_for_cvs_users.txt
===================================================================
--- ./doc/user/SVN/text-base/svn_for_cvs_users.txt Thu Sep 13 15:27:59 2001
+++ ./doc/user/svn_for_cvs_users.txt Mon Sep 17 17:55:45 2001
@@ -29,7 +29,7 @@
* Directory versioning
- tree structures are versioned; no more RCS backend.
- - svn add/unadd, rm/undel works on dirs
+ - svn add, remove works on dirs
- working revnums on dirs *only* increment on updates, else we're lying
- dirprops only committable on up-to-date dirs
Index: ./doc/user/manual/adds.texi
===================================================================
--- ./doc/user/manual/SVN/text-base/adds.texi Mon Sep 10 09:49:56 2001
+++ ./doc/user/manual/adds.texi Mon Sep 17 17:54:34 2001
@@ -46,7 +46,7 @@
(Note that unlike CVS, adding a directory does @emph{not} effect an
immediate change in the repository!)
-@item To undo additions before committing: @samp{svn unadd [items]}
+@item To undo additions before committing: @samp{svn remove [items]}
Because added items have not yet been committed to the repository, it's
easy to make your working copy "forget" that you wanted to add something.
@@ -187,7 +187,7 @@
@end example
At this point, the replaced item acts like any other kind of addition.
-You can undo the replacement by running @samp{svn unadd foo.c} -- and
+You can undo the replacement by running @samp{svn remove foo.c} -- and
the file's status code will revert back to @code{D}. If the replaced
item is a directory, you can schedule items within it for addition as
well.
Re: The unadd, undelete methods and the client README.
Posted by cm...@collab.net.
Mo DeJong <su...@bayarea.net> writes:
> Yes, but by the same token you could just say that these commands
> just add or delete a file to the WC.
That's fair. I suppose it all depends on your perspective.
> That certainly sounds like something revert should do. That would
> provide the current undelete functionality but it would not give us
> the ability to do a `snv undelete dir` on a directory delete that
> has already been committed.
Dude, that deleted dir is in revision history. Now, I don't know how
easy/hard it would be resurrect that directory *and preserve its
versioned history*, but simply recreating it is a one-line shell
command (up'ing to an old version, stripping SVN/ subdirs, add
--recursing that bad boy, and committing). And I think I just saw
someone mail about `svn merge', which is certainly the way to go with
this.
If `revert' got smarter and `unadd' and `undelete' could die, I
wouldn't lose a wink of sleep over that change. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by Mo DeJong <su...@bayarea.net>.
On 17 Sep 2001 13:46:02 -0500
cmpilato@collab.net wrote:
> Mo DeJong <su...@bayarea.net> writes:
>
> > Thanks for the reply Mike. Could I bother you to elaborate a bit more
> > on why doing a `svn add foo.c` and then a `svn delete foo.c` to change
> > your mind before a commit is wrong? Shouldn't the user think of add
> > and delete as inverse operations?
>
> Add and delete may be inverse operations, but the 'add' and 'delete'
> client subcommands are a bit misnamed. `svn add' does not add a file
> to the repository, it merely "schedules" a file for addition to the
> repository. Likewise, `svn delete' merely schedules a file for
> deletion from a repository. Those actions don't really happen until a
> commit occurs.
Yes, but by the same token you could just say that these commands
just add or delete a file to the WC. We don't need to assume that
the user doing the add will be the person doing the commit. A
contributor might send us a patch that adds some new files and
deletes others. The developer assigned to review patches would
actually make the decision as to wether or not to commit to the
repository.
> Actually, let's look even at their inverseness a little bit, too. If
> "add" and "delete" are truly inverse actions, then "unadd" == "delete"
> and "undelete" == "add". But "undelete" is certainly not "add". The
> action sequence "delete foo; add foo" is not a no-op -- it's what we
> call a "replace" operation, and is used to restart the version history
> for "foo."
That is an interesting point. The add/delete operations would be the
same in the case of a new dir or file but a delete on an existing
dir or file seems to call out for an undelete operation. What if
we toss unadd and kept undelete but renamed it to "resurrect"?
The subcommand would be used to bring a deleted entry back to life?
> There is one optional idea I'd like to throw on the table (since there
> don't seem to be enough things to debate about these days).
Well, now is the time to hash out usability issues. After 1.0 it will be too late.
> It occurs
> to me that perhaps unadd and undelete could disappear entirely in
> light of `svn revert.' Can "revert" be used to completely restore a
> given working copy file or directory to it's uncommitted state?
>
> Wouldn't it be cool to do:
>
> svn up .
> svn add foo.c
> svn rm bar.c
> echo "crap, i didn't mean that."
> svn revert .
>
> and have nothing look any different? But that requires more
> brainshare than I have to give right now. Anchors... targets...
> anchors... targets...
That certainly sounds like something revert should do. That would
provide the current undelete functionality but it would not give us
the ability to do a `snv undelete dir` on a directory delete that
has already been committed.
cheers
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by cm...@collab.net.
Mo DeJong <su...@bayarea.net> writes:
> Thanks for the reply Mike. Could I bother you to elaborate a bit more
> on why doing a `svn add foo.c` and then a `svn delete foo.c` to change
> your mind before a commit is wrong? Shouldn't the user think of add
> and delete as inverse operations?
Add and delete may be inverse operations, but the 'add' and 'delete'
client subcommands are a bit misnamed. `svn add' does not add a file
to the repository, it merely "schedules" a file for addition to the
repository. Likewise, `svn delete' merely schedules a file for
deletion from a repository. Those actions don't really happen until a
commit occurs.
Actually, let's look even at their inverseness a little bit, too. If
"add" and "delete" are truly inverse actions, then "unadd" == "delete"
and "undelete" == "add". But "undelete" is certainly not "add". The
action sequence "delete foo; add foo" is not a no-op -- it's what we
call a "replace" operation, and is used to restart the version history
for "foo."
There is one optional idea I'd like to throw on the table (since there
don't seem to be enough things to debate about these days). It occurs
to me that perhaps unadd and undelete could disappear entirely in
light of `svn revert.' Can "revert" be used to completely restore a
given working copy file or directory to it's uncommitted state?
Wouldn't it be cool to do:
svn up .
svn add foo.c
svn rm bar.c
echo "crap, i didn't mean that."
svn revert .
and have nothing look any different? But that requires more
brainshare than I have to give right now. Anchors... targets...
anchors... targets...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by Philip Martin <ph...@ntlworld.com>.
Mo DeJong <su...@bayarea.net> writes:
> I tried to come up with a good reason to include the unadd and undelete
> subcommands. I could not think of anything that could not be done
> using add/delete before doing a commit. One thing about the undelete
> method that did seem interesting was the possibility of using it after
> a commit that removes a directory.
>
> % mkdir newdir
> % svn add newdir
> % touch foo.c
> % svn add foo.c
> % cd ..
> % svn commit newdir -m "added newdir"
Creates revision number N say.
>
> % svn delete newdir
> % svn commit -m "deleted newdir"
Creates revision number N+1 say.
> % svn undelete newdir
> % svn commit -m "woops, I did not want to delete newdir"
Since the changes have been committed to the repository, you don't
need a new command to resurrect the directory, you just need the merge
command to support removing deltas as well as adding them. Basically
you tell the merge command to remove the difference between revisions
N and N+1, just as you would for a normal file. That's what version
control is for.
It might be as simple as
$ svn merge --reverse newdir
to reverse the last change. Or more genrally
$ svn merge -r N+1 --reverse newdir
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: The unadd, undelete methods and the client README.
Posted by Sander Striker <st...@apache.org>.
> From: Sander Striker [mailto:striker@apache.org]
> Sent: 17 September 2001 20:32
> > -----Original Message-----
> > From: Mo DeJong [mailto:supermo@bayarea.net]
> > Sent: 17 September 2001 20:29
>
> [...]
> > I tried to come up with a good reason to include the unadd and undelete
> > subcommands. I could not think of anything that could not be done
> > using add/delete before doing a commit. One thing about the undelete
> > method that did seem interesting was the possibility of using it after
> > a commit that removes a directory.
> >
> > % mkdir newdir
> > % svn add newdir
> > % touch foo.c
> > % svn add foo.c
> > % cd ..
> > % svn commit newdir -m "added newdir"
> >
> > % svn delete newdir
> > % svn commit -m "deleted newdir"
> >
> > % svn undelete newdir
> > % svn commit -m "woops, I did not want to delete newdir"
> >
> > I looked around in svn_wc_undelete but it does not look like
> this is what
> > it was trying to do. Does this seem like a reasonable use case? Is there
> > some other way a user could resurrect a directory that had been deleted?
> > If not, perhaps the undelete subcommand should be retained.
>
> What about:
>
> $ svn revert newdir -rev (current_rev - 1)
>
> ?? Ofcourse I could be way off...
Yes, I am. svn revert seems to be a local command only. Oh well, it felt
intuitive :)
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: The unadd, undelete methods and the client README.
Posted by Sander Striker <st...@apache.org>.
> -----Original Message-----
> From: Mo DeJong [mailto:supermo@bayarea.net]
> Sent: 17 September 2001 20:29
[...]
> I tried to come up with a good reason to include the unadd and undelete
> subcommands. I could not think of anything that could not be done
> using add/delete before doing a commit. One thing about the undelete
> method that did seem interesting was the possibility of using it after
> a commit that removes a directory.
>
> % mkdir newdir
> % svn add newdir
> % touch foo.c
> % svn add foo.c
> % cd ..
> % svn commit newdir -m "added newdir"
>
> % svn delete newdir
> % svn commit -m "deleted newdir"
>
> % svn undelete newdir
> % svn commit -m "woops, I did not want to delete newdir"
>
> I looked around in svn_wc_undelete but it does not look like this is what
> it was trying to do. Does this seem like a reasonable use case? Is there
> some other way a user could resurrect a directory that had been deleted?
> If not, perhaps the undelete subcommand should be retained.
What about:
$ svn revert newdir -rev (current_rev - 1)
?? Ofcourse I could be way off...
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by Mo DeJong <su...@bayarea.net>.
On 17 Sep 2001 09:24:33 -0500
cmpilato@collab.net wrote:
> Mo DeJong <su...@bayarea.net> writes:
>
> > My second question is related to the "unadd" and "undelete" methods included
> > in the svn client. Why do we need a special unadd method to undo an add?
> > Can't the user just call delete on the file or dir?
>
> Currently, the user can call delete to effectively un-add a file. Do
> I think this is proper? Not particularly.
Thanks for the reply Mike. Could I bother you to elaborate a bit more
on why doing a `svn add foo.c` and then a `svn delete foo.c` to change
your mind before a commit is wrong? Shouldn't the user think of add
and delete as inverse operations? If so, don't the unadd and undelete
operations just function as aliases? I know they are different functions,
I am just trying to look at this from a new user's perspective.
> When I first started using CVS (which was only about 3 years ago),
> there were some things I simply did NOT understand. Why was it that
> when I would "add" a directory, it happened immediately, yet adding
> files required a commit?
Or that adding a file without doing a commit required write access to the
CVS repo, what were they thinking?
> Why was it that I couldn't delete
> directories, with or without a commit? Why was it that obviously the
> files I just added weren't really versioned until I committed, yet
> somehow I could delete them? Delete them from what?!
>
> All that aside though, I have no personal connection with the unadd
> command. If the community wishes to lose it, that's fine with me --
> one less thing to debug. :-) (and there are definitely still bugs
> there -- I never got a chance to debug unadd or undelete)
I tried to come up with a good reason to include the unadd and undelete
subcommands. I could not think of anything that could not be done
using add/delete before doing a commit. One thing about the undelete
method that did seem interesting was the possibility of using it after
a commit that removes a directory.
% mkdir newdir
% svn add newdir
% touch foo.c
% svn add foo.c
% cd ..
% svn commit newdir -m "added newdir"
% svn delete newdir
% svn commit -m "deleted newdir"
% svn undelete newdir
% svn commit -m "woops, I did not want to delete newdir"
I looked around in svn_wc_undelete but it does not look like this is what
it was trying to do. Does this seem like a reasonable use case? Is there
some other way a user could resurrect a directory that had been deleted?
If not, perhaps the undelete subcommand should be retained.
cheers
Mo DeJong
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by cm...@collab.net.
Mo DeJong <su...@bayarea.net> writes:
> My second question is related to the "unadd" and "undelete" methods included
> in the svn client. Why do we need a special unadd method to undo an add?
> Can't the user just call delete on the file or dir?
Currently, the user can call delete to effectively un-add a file. Do
I think this is proper? Not particularly.
When I first started using CVS (which was only about 3 years ago),
there were some things I simply did NOT understand. Why was it that
when I would "add" a directory, it happened immediately, yet adding
files required a commit? Why was it that I couldn't delete
directories, with or without a commit? Why was it that obviously the
files I just added weren't really versioned until I committed, yet
somehow I could delete them? Delete them from what?!
All that aside though, I have no personal connection with the unadd
command. If the community wishes to lose it, that's fine with me --
one less thing to debug. :-) (and there are definitely still bugs
there -- I never got a chance to debug unadd or undelete)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The unadd, undelete methods and the client README.
Posted by Ben Collins-Sussman <su...@collab.net>.
Mo DeJong <su...@bayarea.net> writes:
> One of the things I found in svn-manual.html was the "unadd" and
> "undelete" subcommands for the svn client. There was no mention of
> these commands in the README. Should the client README be retired?
> It seems to describe lots of features that do not exist. It also
> describes other features that do not yet exist. Would it be better
> to move this into a new texi file in the doc/user/manual directory?
> I would be willing to do that work if it seems like a good idea.
Mo, see doc/user/manual/. It's the start of a user manual. All
add/rm/unadd/unrm behavior is documented there.
>
> My second question is related to the "unadd" and "undelete" methods included
> in the svn client. Why do we need a special unadd method to undo an add?
> Can't the user just call delete on the file or dir?
Yes, if you 'svn rm' a file that has just been added via 'svn add',
this is equivalent to an 'svn unadd'. Either way works.
> % mkdir foo
> % svn add foo
> % svn unadd foo
> svn_error: #21026 : <Can't find an entry>
> No default entry in directory `foo'
This is probably a plain old bug that needs to be filed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org