You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2004/03/18 21:50:19 UTC
error committing a deleted dir
Hi,
As I found out, it's not possible to commit a deleted folder which had
another deleted folder in it non-recursively. I know this is probably
not a problem to most of you, but to me and TSVN it is a big one.
I'll try to explain:
imagine the following wc structure:
parent/child1/child2/file2
parent/child1/file1
parent/file3
parent/file4
now do
svn rm parent/child1
time /t >> parent/file3
time /t >> parent/file4
svn propset customprop customvalue parent
so the folder child1 and child2 are marked for deletion, and file3 and
file4 are modified. Also the parent folder is modified.
now I want to commit everything except parent/file3.
svn ci parent/child1 parent parent/file4 -N -m "some log message"
Deleting parent/child1
...
svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: Working copy "path/fo/wc child1/child2" not locked
after that, even an 'svn cleanup' fails, because there's a file named
KILLME inside the .svn folder in child2.
Sure, this is a very rare case for users of the command line client
because most of the time you're using the default recursive commit. But
TortoiseSVN does always non-recursive commits because it let's the user
select which changes to commit, and if a modified file is marked for not
committing then a recursive commit of the parent folder would still
commit that file.
I hope there's an easy fix for this, because TSVN depends on it. I don't
want to force the user to commit such deleted folders separately since
this would mean creating another revision.
Also, the function svn_client_commit() errors out if TSVN passes all the
paths to it (i.e. parent/child1, parent/child1/file1,
parent/child2/file2, parent/child2, ...). I can work around this, but
not around the case mentioned above.
Stefan
---
My opinions may have changed, but not the fact that I am right.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for issue 1797 - take four
Posted by makl <ma...@tigris.org>.
[[[
Fix for issue 1797. non-recursive delete of directory tree fails
Patch from <ma...@tigris.org>
* subversion/include/svn_wc.h
Add new function svn_wc_adm_extend.
* subversion/libsvn_wc/lock.c
(do_open): Allow locking of directories that are already locked.
(svn_wc_adm_open2):
(svn_wc__adm_pre_open):
Add the new parameters to the call of do_open.
(svn_wc_adm_extend): New function. This function is similar to
svn_wc_adm_open2 but doesn't return a SVN_ERR_WC_LOCKED error if
the directory has already a lock in associated.
* subversion/libsvn_client/commit.c
(svn_client_commit): Always lock deleted directories recursive.
* subversion/libsvn_client/commit_util.c
(svn_client__do_commit): Remove any deleted entries where the parent
is deleted too.
* subversion/tests/clients/cmdline/commit_tests.py
(commit_deleted_directory_tree_non_recursive_1): New
regression test for case one.
(commit_deleted_directory_tree_non_recursive_2_1): New
regression test for case two with one deleted directory.
(commit_deleted_directory_tree_non_recursive_2_1): New
regression test for case two with three independent deleted
directories.
]]]
Re: [PATCH] Fix for issue 1797 - take three
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
>>>>@@ -329,22 +329,29 @@
>>>> static svn_error_t *
>>>> do_open (svn_wc_adm_access_t **adm_access,
>>>> svn_wc_adm_access_t *associated,
>>>>+ const svn_wc_adm_access_t *root_associated,
>>> I don't see why you added this additional access baton parameter, it
>>> looks like you could just use associated.
>>
>> Look at the recursion. In the next subdirectory, associated has an empty
>> set.
>
> Could the recursive call pass associated rather than the new lock?
No, probably not. It looks like we need two access batons :-(
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for issue 1797 - take three
Posted by Philip Martin <ph...@codematters.co.uk>.
makl <ma...@tigris.org> writes:
> Philip Martin wrote:
>
>> makl <ma...@tigris.org> writes:
>>
>>>Index: subversion/libsvn_wc/lock.c
>>>===================================================================
>>>--- subversion/libsvn_wc/lock.c (revision 9290)
>>>+++ subversion/libsvn_wc/lock.c (working copy)
>>>@@ -329,22 +329,29 @@
>>> static svn_error_t *
>>> do_open (svn_wc_adm_access_t **adm_access,
>>> svn_wc_adm_access_t *associated,
>>>+ const svn_wc_adm_access_t *root_associated,
>> I don't see why you added this additional access baton parameter, it
>> looks like you could just use associated.
>
> Look at the recursion. In the next subdirectory, associated has an empty
> set.
Could the recursive call pass associated rather than the new lock?
>>>+
>>>+ if (lock == &missing)
>>>+ lock = NULL;
>> I think we need to verify the type of the lock, if write_lock is set
>> it's probably not acceptable to use a read-only lock.
>
> missing is a static entry declared in line 80. It has no meaningful
> information, so there is nothing to check.
My comment wasn't directed at missing in particular, but at the fact
that there was no check for the type.
>> Hmm, now I see you are upgrading read-only locks into write locks, but
>> you didn't document this behaviour anywhere. As far as I can tell it
>> even upgrades existing read-only locks! That won't work, not unless
>> the entries cache is thrown away and repopulated. I don't like it,
>> I'd prefer locks not to change type. That's the reason
>> adm_access_alloc takes a lock type; once allocated it never changes.
>
> Can we accept write locks if read locks are requested?
I don't know. If the calling code is making assumptions about the
behaviour of the entries cache (assuming it won't change because it's
read-only) then it's probably safer to return an error.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for issue 1797 - take three
Posted by makl <ma...@tigris.org>.
Philip Martin wrote:
> makl <ma...@tigris.org> writes:
>
>
>>Index: subversion/libsvn_wc/lock.c
>>===================================================================
>>--- subversion/libsvn_wc/lock.c (revision 9290)
>>+++ subversion/libsvn_wc/lock.c (working copy)
>>@@ -329,22 +329,29 @@
>> static svn_error_t *
>> do_open (svn_wc_adm_access_t **adm_access,
>> svn_wc_adm_access_t *associated,
>>+ const svn_wc_adm_access_t *root_associated,
>
>
> I don't see why you added this additional access baton parameter, it
> looks like you could just use associated.
Look at the recursion. In the next subdirectory, associated has an empty
set.
>>+
>>+ if (lock == &missing)
>>+ lock = NULL;
>
>
> I think we need to verify the type of the lock, if write_lock is set
> it's probably not acceptable to use a read-only lock.
missing is a static entry declared in line 80. It has no meaningful
information, so there is nothing to check.
> Hmm, now I see you are upgrading read-only locks into write locks, but
> you didn't document this behaviour anywhere. As far as I can tell it
> even upgrades existing read-only locks! That won't work, not unless
> the entries cache is thrown away and repopulated. I don't like it,
> I'd prefer locks not to change type. That's the reason
> adm_access_alloc takes a lock type; once allocated it never changes.
Can we accept write locks if read locks are requested?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for issue 1797 - take three
Posted by Philip Martin <ph...@codematters.co.uk>.
makl <ma...@tigris.org> writes:
> Index: subversion/libsvn_wc/lock.c
> ===================================================================
> --- subversion/libsvn_wc/lock.c (revision 9290)
> +++ subversion/libsvn_wc/lock.c (working copy)
> @@ -329,22 +329,29 @@
> static svn_error_t *
> do_open (svn_wc_adm_access_t **adm_access,
> svn_wc_adm_access_t *associated,
> + const svn_wc_adm_access_t *root_associated,
I don't see why you added this additional access baton parameter, it
looks like you could just use associated.
> const char *path,
> svn_boolean_t write_lock,
> int depth,
> svn_boolean_t under_construction,
> + svn_boolean_t allow_existing_locks,
This parameter I understand, although neither parameter is documented.
> apr_pool_t *pool)
> {
> - svn_wc_adm_access_t *lock;
> + svn_wc_adm_access_t *lock = NULL;
> int wc_format;
> svn_error_t *err;
> + svn_boolean_t is_new_lock = FALSE;
>
> if (associated)
> {
> adm_ensure_set (associated);
>
> lock = apr_hash_get (associated->set, path, APR_HASH_KEY_STRING);
> - if (lock && lock != &missing)
> +
> + if (! lock && root_associated && allow_existing_locks)
> + lock = apr_hash_get (root_associated->set, path, APR_HASH_KEY_STRING);
> +
> + if (lock && lock != &missing && ! allow_existing_locks)
> /* Already locked. The reason we don't return the existing baton
> here is that the user is supposed to know whether a directory is
> locked: if it's not locked call svn_wc_adm_open, if it is locked
That comment is now a bit odd.
> @@ -352,9 +359,12 @@
> return svn_error_createf (SVN_ERR_WC_LOCKED, NULL,
> "Working copy '%s' locked",
> path);
> +
> + if (lock == &missing)
> + lock = NULL;
I think we need to verify the type of the lock, if write_lock is set
it's probably not acceptable to use a read-only lock.
> }
>
> - if (! under_construction)
> + if (! under_construction && ! lock)
> {
> /* By reading the format file we check both that PATH is a directory
> and that it is a working copy. */
> @@ -377,19 +387,21 @@
> pool));
> }
>
> + if (! lock)
> + {
> + lock = adm_access_alloc (svn_wc__adm_access_unlocked, path, pool);
Why unlocked? Is it possible to get here when write_lock is set?
> + is_new_lock = TRUE;
> + }
> +
> /* Need to create a new lock */
> - if (write_lock)
> + if (write_lock && lock->type != svn_wc__adm_access_write_lock)
> {
> - lock = adm_access_alloc (svn_wc__adm_access_write_lock, path, pool);
> + lock->type = svn_wc__adm_access_write_lock;
Hmm, now I see you are upgrading read-only locks into write locks, but
you didn't document this behaviour anywhere. As far as I can tell it
even upgrades existing read-only locks! That won't work, not unless
the entries cache is thrown away and repopulated. I don't like it,
I'd prefer locks not to change type. That's the reason
adm_access_alloc takes a lock type; once allocated it never changes.
> SVN_ERR (create_lock (lock, 0, pool));
> lock->lock_exists = TRUE;
> }
> - else
> - {
> - lock = adm_access_alloc (svn_wc__adm_access_unlocked, path, pool);
> - }
>
> - if (! under_construction)
> + if (! under_construction && is_new_lock)
> {
> lock->wc_format = wc_format;
> if (write_lock)
> @@ -433,8 +445,9 @@
> entry_path = svn_path_join (lock->path, entry->name, subpool);
>
> /* Don't use the subpool pool here, the lock needs to persist */
> - err = do_open (&entry_access, lock, entry_path, write_lock, depth,
> - FALSE, lock->pool);
> + err = do_open (&entry_access, lock, root_associated, entry_path,
> + write_lock, depth,
> + FALSE, allow_existing_locks, lock->pool);
> if (err)
> {
> if (err->apr_err != SVN_ERR_WC_NOT_DIRECTORY)
> @@ -494,8 +507,9 @@
> when the cleanup handler runs. If the apr_xlate_t cleanup handler
> were to run *before* the access baton cleanup handler, then the access
> baton's handler won't work. */
> - apr_pool_cleanup_register (lock->pool, lock, pool_cleanup,
> - pool_cleanup_child);
> + if (is_new_lock)
> + apr_pool_cleanup_register (lock->pool, lock, pool_cleanup,
> + pool_cleanup_child);
> *adm_access = lock;
> return SVN_NO_ERROR;
> }
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for issue 1797 - take three
Posted by makl <ma...@tigris.org>.
[[[
Fix for issue 1797. non-recursive delete of directory tree fails
Patch from <ma...@tigris.org>
* subversion/include/svn_wc.h
Add new function svn_wc_adm_extend.
* subversion/libsvn_wc/lock.c
(do_open): Allow locking of directories that are already locked.
(svn_wc_adm_open2):
(svn_wc__adm_pre_open):
Add the new parameters to the call of do_open.
(svn_wc_adm_extend): New function. This function is similar to
svn_wc_adm_open2 but doesn't return a SVN_ERR_WC_LOCKED error if
the directory has already a lock in associated.
* subversion/libsvn_client/commit.c
(svn_client_commit): Always lock deleted directories recursive.
* subversion/libsvn_client/commit_util.c
(svn_client__do_commit): Remove any deleted entries where the parent
is deleted too.
* subversion/tests/clients/cmdline/commit_tests.py
(commit_deleted_directory_tree_non_recursive_1): New
regression test for case one.
(commit_deleted_directory_tree_non_recursive_2_1): New
regression test for case two with one deleted directory.
(commit_deleted_directory_tree_non_recursive_2_1): New
regression test for case two with three independent deleted
directories.
]]]
Re: [PATCH] Fix for issue 1797 case two. A non-recursive commit of
a deleted directory fails post-commit.
Posted by makl <ma...@tigris.org>.
Philip Martin wrote:
> It's unfortunate that a temporary adm_open is required as that means
> reading the entries file twice. It's also a race since it's making a
> decision based on the read-only access baton, and that may not be
> valid once the write baton is taken. I don't think either of these is
> a serious problem, but I wonder if there is a better way to do it.
>
> How about using the existing code to open the access batons, i.e. the
> loop over dirs_to_lock and dirs_to_lock_recursive, and then doing
> something like
>
> for dir in dirs_to_lock
> get entry for dir
> if schedule delete
> for each entry in dir
> if entry is dir
> try adm_retrieve for entry
> if not locked
> take recursive lock for entry
>
> I suppose that would fail if dirs_to_lock contained an item that was
> within another schedule delete item:
Correct.
> svn commit -N foo foo/bar/baz
>
> where foo is schedule delete. Personally I'd accept that as a valid
> way to fail, but others may not agree.
This is one of the use cases.
> This is really another case for svn_wc_adm_extend, a function that was
> never written. This mythical function would have an interface like
> svn_wc_adm_open, but would not produce an error if the associated
> access baton already contained any of the required locks. It's quite
> possible this should be the default behaviour for svn_wc_adm_open.
If this is a desired functionality I can give it a try. But that new
function can't be backported to 1.0.x.
My suggestion is to use the current patch to fix the problem in 1.0.x
and I will make a new patch for 1.1.x with svn_wc_adm_extend.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for issue 1797 case two. A non-recursive commit of
a deleted directory fails post-commit.
Posted by Philip Martin <ph...@codematters.co.uk>.
makl <ma...@tigris.org> writes:
> Index: subversion/libsvn_client/commit.c
> ===================================================================
> --- subversion/libsvn_client/commit.c (revision 9193)
> +++ subversion/libsvn_client/commit.c (working copy)
> @@ -1016,6 +1016,29 @@
> return SVN_NO_ERROR;
> }
>
> +/* Check if a directory must be locked even in non recursive mode.
> + Currently this is the case for deleted directories. */
> +static svn_error_t *
> +check_for_recursive_locking(svn_boolean_t *is_deleted,
> + const char *path,
> + apr_pool_t *pool)
> +{
> + *is_deleted = FALSE;
> +
> + const svn_wc_entry_t *tmp_entry;
> + svn_wc_adm_access_t *tmp_adm_access;
> +
> + SVN_ERR (svn_wc_adm_open2 (&tmp_adm_access, NULL, path, FALSE, 0, pool));
> + SVN_ERR (svn_wc_entry (&tmp_entry, path, tmp_adm_access, TRUE, pool));
> +
> + if (!tmp_entry || (tmp_entry->schedule == svn_wc_schedule_delete))
> + *is_deleted = TRUE;
> +
> + SVN_ERR (svn_wc_adm_close (tmp_adm_access));
> +
> + return SVN_NO_ERROR;
> +}
It's unfortunate that a temporary adm_open is required as that means
reading the entries file twice. It's also a race since it's making a
decision based on the read-only access baton, and that may not be
valid once the write baton is taken. I don't think either of these is
a serious problem, but I wonder if there is a better way to do it.
How about using the existing code to open the access batons, i.e. the
loop over dirs_to_lock and dirs_to_lock_recursive, and then doing
something like
for dir in dirs_to_lock
get entry for dir
if schedule delete
for each entry in dir
if entry is dir
try adm_retrieve for entry
if not locked
take recursive lock for entry
I suppose that would fail if dirs_to_lock contained an item that was
within another schedule delete item:
svn commit -N foo foo/bar/baz
where foo is schedule delete. Personally I'd accept that as a valid
way to fail, but others may not agree.
This is really another case for svn_wc_adm_extend, a function that was
never written. This mythical function would have an interface like
svn_wc_adm_open, but would not produce an error if the associated
access baton already contained any of the required locks. It's quite
possible this should be the default behaviour for svn_wc_adm_open.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix for issue 1797 case two. A non-recursive commit of
a deleted directory fails post-commit.
Posted by makl <ma...@tigris.org>.
Version two of the patch. This time for the complete issue.
[[[
Fix for issue 1797. non-recursive delete of directory tree fails
Patch from <ma...@tigris.org>
* subversion/libsvn_client/commit.c
(check_for_recursive_locking): New function.
(svn_client_commit): Always lock deleted directories recursive.
* subversion/libsvn_client/commit_util.c
(svn_client__do_commit): Don't commit items where the parent is
deleted too.
* subversion/tests/clients/cmdline/commit_tests.py
(commit_deleted_directory_tree_non_recursive_1): New
regression test for case one.
(commit_deleted_directory_tree_non_recursive_2_1): New
regression test for case two with one deleted directory.
(commit_deleted_directory_tree_non_recursive_2_1): New
regression test for case two with three independent deleted
directories.
]]]
Re: [PATCH] Fix for issue 1797 case two. A non-recursive commit of
a deleted directory fails post-commit.
Posted by Philip Martin <ph...@codematters.co.uk>.
makl <ma...@tigris.org> writes:
> [[[
> Fix for issue 1797 case two. A non-recursive commit of a deleted
> directory fails post-commit.
>
> Patch from <ma...@tigris.org>
It's a bit mangled, both the log message and the patch itself appear
to combine the library changes and the test changes into a change to
one file.
>
> * subversion/libsvn_client/commit.c
> (svn_client_commit): Always lock deleted directories recursive.
> (commit_deleted_directory_tree_non_recursive_1): New
> regression test for case one. Currently XFail.
> (commit_deleted_directory_tree_non_recursive_2_1): New
> regression test for case two with one deleted directory.
> (commit_deleted_directory_tree_non_recursive_2_1): New
> regression test for case two with three independent deleted
> directories.
> ]]]
>
>
> Index: subversion/libsvn_client/commit.c
> ===================================================================
> --- subversion/libsvn_client/commit.c (revision 9145)
> +++ subversion/libsvn_client/commit.c (working copy)
> @@ -1097,8 +1097,25 @@
> /* If the final target is a dir, we want to recursively lock it */
> if (kind == svn_node_dir)
> {
> +
> if (nonrecursive)
> - APR_ARRAY_PUSH (dirs_to_lock, const char *) = target;
> + {
> + const svn_wc_entry_t *tmp_entry;
> + svn_wc_adm_access_t *tmp_adm_access;
> +
> + SVN_ERR (svn_wc_adm_open2 (&tmp_adm_access, NULL, target,
> + FALSE, 0, pool));
> + SVN_ERR (svn_wc_entry (&tmp_entry, target, tmp_adm_access,
> + TRUE, pool));
> + if (!tmp_entry
> + || (tmp_entry->schedule == svn_wc_schedule_delete))
> + APR_ARRAY_PUSH (dirs_to_lock_recursive,
> + const char *) = target;
> + else
> + APR_ARRAY_PUSH (dirs_to_lock, const char *) = target;
> +
> + SVN_ERR (svn_wc_adm_close (tmp_adm_access));
> + }
> else
> APR_ARRAY_PUSH (dirs_to_lock_recursive, const char *) = target;
> }
> @@ -1141,8 +1158,26 @@
> if (kind == svn_node_dir)
> {
> if (nonrecursive)
> - APR_ARRAY_PUSH (dirs_to_lock,
> - const char *) = apr_pstrdup (pool, target);
> + {
> + const svn_wc_entry_t *tmp_entry;
> + svn_wc_adm_access_t *tmp_adm_access;
> +
> + SVN_ERR (svn_wc_adm_open2 (&tmp_adm_access, NULL, target,
> + FALSE, 0, subpool));
> + SVN_ERR (svn_wc_entry (&tmp_entry, target, tmp_adm_access,
> + TRUE, subpool));
> + if (!tmp_entry
> + || (tmp_entry->schedule == svn_wc_schedule_delete))
> + APR_ARRAY_PUSH (dirs_to_lock_recursive,
> + const char *) = apr_pstrdup (pool,
> + target);
> + else
> + APR_ARRAY_PUSH (dirs_to_lock,
> + const char *) = apr_pstrdup (pool,
> + target);
> +
> + SVN_ERR (svn_wc_adm_close (tmp_adm_access));
> + }
> else
> APR_ARRAY_PUSH (dirs_to_lock_recursive,
> const char *) = apr_pstrdup (pool, target);
That looks like almost identical code twice, could the bits be combined?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Fix for issue 1797 case two. A non-recursive commit of a
deleted directory fails post-commit.
Posted by makl <ma...@tigris.org>.
[[[
Fix for issue 1797 case two. A non-recursive commit of a deleted
directory fails post-commit.
Patch from <ma...@tigris.org>
* subversion/libsvn_client/commit.c
(svn_client_commit): Always lock deleted directories recursive.
(commit_deleted_directory_tree_non_recursive_1): New
regression test for case one. Currently XFail.
(commit_deleted_directory_tree_non_recursive_2_1): New
regression test for case two with one deleted directory.
(commit_deleted_directory_tree_non_recursive_2_1): New
regression test for case two with three independent deleted
directories.
]]]
[Issue 1797] non-recursive delete of directory tree fails
Posted by makl <ma...@tigris.org>.
> $ svn mkdir wc/foo wc/foo/bar
> $ svn ci wc -m "create"
> $ svn rm wc/foo
>
> A non-recursive commit of both directories fails:
>
> $ svn ci wc/foo wc/foo/bar -N -m "commit fail"
> Deleting wc/foo
> ../svn/subversion/libsvn_client/commit.c:747: (apr_err=160028)
> svn: Commit failed (details follow):
> ../svn/subversion/libsvn_repos/commit.c:114: (apr_err=160028)
> svn: Out of date: 'foo' in transaction '2'
> ../svn/subversion/clients/cmdline/util.c:348: (apr_err=160028)
> svn: Your commit message was left in a temporary file:
> ../svn/subversion/clients/cmdline/util.c:349: (apr_err=160028)
> svn: '/home/pm/sw/subversion/obj/wc/svn-commit.tmp'
This part of the issue is a general commit problem and not limited to
the deletion of subdirectories.
$ svn --version
svn, version 1.0.0
compiled Feb 25 2004, 18:32:49
[...]
$ svnadmin create --bdb-txn-nosync repo
$ svn co file:///g:/repos/repo wc1
$ svn mkdir wc1/foo
$ svn ci wc1 -m "r1"
$ svn propset customprop customvalue wc1
$ time /t 1>wc1\foo\file2
$ svn add wc1\foo\file2
$ svn ci wc1 wc1/foo/file2 -N -m "commit fail"
svn: Commit failed (details follow):
svn: Out of date: '' in transaction '2'
Sending wc1
I think that Stefan and other authors of clients will have a large
problem with the present behavior.
IMHO is this a priority P1 defect (Bad first impression).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org