Log problem
Hi, I've run over a strange situation and want to know if this is OK to happen (in my opinion it shouldn't). These are the details: - one of our servers has a repository with Subversion 1.4 format - I have a working copy from a given repository path, let it be "http://R/svn/repos/userguide"; - in my working copy, one of the folders has an external folder X, pointing to "http://R/svn/repos/branches/rel/doc"; - I modify a file from the external folder X and commit it - when looking over the log information of the root of my working copy, there is no entry for the commit which I've just made (this is OK, I've committed to an external resource) - after, I look over the log information of the folder at which my working copy external folder targets. There is no information about my commit there either, which is strange, I've committed from my external folder which is pointing to this one. - the folder to which my working copy external folder is pointing was copied from another branch, and if I do a log on that branch (the original one), then I can see my commit, which again is strange: why the commit goes there and not to the HEAD of the branch to which my external folder is pointing. I don't know if the above information helps you somehow, but I would like to know if this would be possible and if this is a repository side problem, taking into account that the repository has an old version (1.4). Thank you. Best Regards, Florin
Re: Log problem
Hi, Thank you for your reply. My folders are up to date in my working copy, but the log information is the same either when requested on working copy resources or when using the repository URLs. Is strange that there is a long time since I work with this working copy structure and suddenly something which worked fine seems to be broken. Have any idea about what else could trigger this behavior ?! Best Regards, Florin From: Ryan Schmidt To: Florin Avram Cc: users@subversion.apache.org Sent: Wed, November 3, 2010 4:10:52 PM Subject: Re: Log problem On Nov 3, 2010, at 05:54, Florin Avram wrote: > I've run over a strange situation and want to know if this is OK to happen > (in >my opinion it shouldn't). These are the details: > - one of our servers has a repository with Subversion 1.4 format > - I have a working copy from a given repository path, let it be >"http://R/svn/repos/userguide"; > - in my working copy, one of the folders has an external folder X, pointing > to >"http://R/svn/repos/branches/rel/doc"; > - I modify a file from the external folder X and commit it > - when looking over the log information of the root of my working copy, there >is no entry for the commit which I've just made (this is OK, I've committed to >an external resource) > - after, I look over the log information of the folder at which my working > copy >external folder targets. There is no information about my commit there either, >which is strange, I've committed from my external folder which is pointing to >this one. Is the folder up to date? Use "svn up" and try again. > - the folder to which my working copy external folder is pointing was copied >from another branch, and if I do a log on that branch (the original one), then >I >can see my commit, which again is strange: why the commit goes there and not >to >the HEAD of the branch to which my external folder is pointing. > > I don't know if the above information helps you somehow, but I would like to >know if this would be possible and if this is a repository side problem, >taking >into account that the repository has an old version (1.4). I doubt any problem exists.
status -u does not show removed directories
Hi, If having an SVN 1.7 working copy which was deleted from the repository, svn status -u does not report any remote change, unless using svn status -u -v Is this OK? I would expect to report that there are remote changes. This was the behavior in SVN 1.6. Regards, Florin Avram
Wrong state for SWITCHED items
Hi, Two things I've noticed: 1) svn status switched.txt => file reported as switched svn delete --keep-local switched.txt svn status switched.txt => the file is reported as DELETED, but not as SWITCHED anymore (although "svn info" indicates the correct URL from the branch) 2) Also, why can I delete a switched file, but I cannot delete a switched directory?! cd wcRootDir svn delete --keep-local switchedDirectory => svn: E155005: No write-lock in 'D:\path\to\wcRootDir' Thanks, Florin
Re: Wrong state for SWITCHED items
Hi,
Thank you for your prompt reply.
The exact behavior (just tested on my own):
SVN 1.6:
switched file
- delete: works;
- status: reported correctly (D + S);
- commit: works (removes item from the branch URL, not from the parent
directory URL);
switched directory
- delete: works;
- status: reported wrong if directly on the switched directory ("svn status switchedDir"
reports as D only), but works fine if requested on parent dir ("svn status ." reports
"switchedDir" as D + S);
- commit: works fine;
SVN 1.7:
switched file
- delete: works;
- status: loses S state, only D reported (both if "svn status" on file or
on parent);
- commit: same as SVN 1.6 for file;
switched directory
- delete:not working (previously mentioned error);
I don't know how things work for SVN 1.8, since I do not test it until
officially available.
At this point, I assume it would be safer to not allow delete on switched items
(especially if the switched status is lost) since the user might not be aware
that commits something to another repository location.
But, this will prevent a user from replacing the switched item (delete + add).
Best Regards,
Florin
On 04.04.2013 15:19, Bert Huijben wrote:
-Original Message-
From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
Philip Martin
Sent: donderdag 4 april 2013 12:42
To: Florin Avram
Cc: users@subversion.apache.org
Subject: Re: Wrong state for SWITCHED items
Florin Avram writes:
Two things I've noticed:
1) svn status switched.txt => file reported as switched
svn delete --keep-local switched.txt
svn status switched.txt => the file is reported as DELETED, but not as
SWITCHED anymore (although "svn info" indicates the correct URL from
the branch)
I think that's a bug. In particular while info shows the switched URL
commit will delete the unswitched URL. Combining switch with delete is
always a problem, for example this old bug:
http://subversion.tigris.org/issues/show_bug.cgi?id=1906
2) Also, why can I delete a switched file, but I cannot delete a
switched directory?!
cd wcRootDir
svn delete --keep-local switchedDirectory => svn: E155005: No
write-lock in 'D:\path\to\wcRootDir'
That's a bug as well. Preventing the delete of a switched node may be a
good idea but the error message should be better.
This error is caused by our 'anchor' rules. A switched directory doesn't use
its parent directory for many operations. (For a file it must always use the
directory). In this case we obtain the lock for the to be deleted node only,
while we delete a child from its ancestor.
Is this 1.6 or 1.7?
Bert
Re: SVN 1.7 - can delete external files
Hi, Well, I don't know how often this situation can be seen, so it is up to you (SVN developers) to decide what to do (I just signaled the issue). Regards, Florin On 05.04.2013 17:41, Stefan Sperling wrote: On Fri, Apr 05, 2013 at 05:12:10PM +0300, Syncro SVN Client Support wrote: Hi, I found that you can delete external files with SVN 1.7, which should not be allowed. Below are some test I've done with SVN 1.6 and SVN 1.7 over external files and directories. *I.**external file* *1.**SVN 1.6* - neither "svn delete external.txt" or "svn delete --keep-local external.txt" work (which is fine, according with the SVN Book). svn: E155030: Cannot remove the file external at 'external.txt'; please propedit or propdel the svn:externals description that created itII. external dir *2**. SVN 1.7.8* - "svn delete external.txt" throws same error (OK). But, "svn delete --keep-local" works, file is removed and the EXTERNAL status is lost. svn delete --keep-local external.txt D external.txt svn status external.txt D external.txt svn status . (on parent directory) D external.txt svn commit -m "test" external.txt Deleting external.txt Committed revision 3128. * **II**.**external dir* SVN 1.6.17 allows deleting external directories, but SVN 1.7 denies deletion of external directories (an error like "cannot delete the root of a working copy"). In the end, I assume "svn delete" should not work for an external item, ignoring the SVN version, the item type (file or dir) and any option for delete (like --force or --keep-local), no? Regards, Florin Yes, I agree. The trunk code had the same issue, but with slightly different output. Fixed in http://svn.apache.org/r1464992 Do you think this is an important enough issue to warrant a backport to 1.7?
Re: SVN 1.7 - can delete external files
On 08.04.2013 11:01, Daniel Shahaf wrote: [CC += dev@, so fullquote; please drop users@ on replies] Florin Avram wrote on Mon, Apr 08, 2013 at 08:51:30 +0300: On 05.04.2013 17:41, Stefan Sperling wrote: On Fri, Apr 05, 2013 at 05:12:10PM +0300, Syncro SVN Client Support wrote: Hi, I found that you can delete external files with SVN 1.7, which should not be allowed. Below are some test I've done with SVN 1.6 and SVN 1.7 over external files and directories. *I.**external file* *1.**SVN 1.6* - neither "svn delete external.txt" or "svn delete --keep-local external.txt" work (which is fine, according with the SVN Book). svn: E155030: Cannot remove the file external at 'external.txt'; please propedit or propdel the svn:externals description that created itII. external dir *2**. SVN 1.7.8* - "svn delete external.txt" throws same error (OK). But, "svn delete --keep-local" works, file is removed and the EXTERNAL status is lost. svn delete --keep-local external.txt D external.txt svn status external.txt D external.txt svn status . (on parent directory) D external.txt svn commit -m "test" external.txt Deleting external.txt Committed revision 3128. * **II**.**external dir* SVN 1.6.17 allows deleting external directories, but SVN 1.7 denies deletion of external directories (an error like "cannot delete the root of a working copy"). In the end, I assume "svn delete" should not work for an external item, ignoring the SVN version, the item type (file or dir) and any option for delete (like --force or --keep-local), no? Regards, Florin Yes, I agree. The trunk code had the same issue, but with slightly different output. Fixed in http://svn.apache.org/r1464992 Do you think this is an important enough issue to warrant a backport to 1.7? Hi, Well, I don't know how often this situation can be seen, so it is up to you (SVN developers) to decide what to do (I just signaled the issue). What happens after someone deletes (or deletes-and-commits) a file external? Would revert+cleanup restore the working copy to a valid state, or would he need to checkout a fresh wc? Daniel Regards, Florin Another thing to have in sight: what happens if deleting a directory containing EXTERNAL items?! Testing with SVN 1.7.8, items are reported as DELETED and the EXTERNAL state is lost, so, again, I can delete (and commit as deleted) EXTERNAL files. And a last thing, regarding SWITCHED items: shouldn't they be treated same as EXTERNAL ones in what regards the "svn delete" command? What I mean is that either you delete and EXTERNAL item or a SWITCHED item, you will commit (and remove from repository) an item which is not from the branch you work on, but from a different location of the repository (or a different repository, for EXTERNAL dirs). Furthermore, deleting and committing a SWITCHED item can confuse you if you don't pay attention: after committing it as deleted, and doing an update on the parent directory, you get it back on your working copy, but this time it is from the branch you work on (the original URL). And you ask yourself: "Didn't I already deleted this item?!" Looking at what happens with both SVN 1.6 and SVN 1.7, my conclusion is that it should be better if "svn delete" should never work for EXTERNAL and SWITCHED items (and only for them), but should work for their children (since you can see the parent is from another repository location). This is due to the fact that "svn delete" is a "destructive" operation and should be performed only for items being on the same branch as their parent directory (make users aware about where they work). Consequently, replacing EXTERNAL and SWITCHED items would not be allowed.
Strange behavior after replacing directory
Hi, I've found a strange behavior in the situation described below and wanted to let you know - I think there could be an issue or a need of improvement (don't know what exactly). Subversion: 1.8.x, 1.7.x. The situation is as follows (the minimum necessary to reproduce the issue): - have a working copy with a folder and a file inside the folder; - replace the folder and commit: svn delete folder/file svn delete --keep-local folder svn add folder (consider it as a new folder) svn commit folder (both folder and file) make new "file" inside folder svn add folder/file svn commit folder/file - now, in another working copy: svn status -u- reports folder as replaced and file as deleted svn update folder/file - svn indicates that file was updated fine svn statsus -u - again, both folder and file are reported as previously (replaced and deleted) Repeating the file update and "svn status" goes on and on as file updated correctly and file reported as deleted again. Only after updating the folder everything works fine. My question(s): - is this OK to happen like this? My colleagues started to be confused since they saw the file exists in the repository, but it was reported as DELETED in the working copy and an "svn update" seemed to work until checking again if there are other changes in the working copy; - if "svn update" should work, then there is an issue, because the file is reported back as DELETED on an "svn status -u". - if it is correct not to work, because of the dependency between the file and the parent dir being replaced, at least should provide a meaningful message to upgrade the parent also. Or at least it should skip the item, like in the case when a directory is added and you try to update only one of its children. Can you tell if this is the correct behavior or this is an issue?! Thank you, Florin
Re: Strange behavior after replacing directory
Hi, Thank you for the quick reply. Strange thing. I was expecting that the repository will notify me only about the items/revisions/changes I am missing. If the update of the file was successful, then when "svn status -u folder", the repository should report that only the folder has changes (it was replaced), but the file is already updated. Somehow, this can be misleading, even more if users are not very SVN-experimented. Best Regards, Florin On 30.09.2013 12:54, Stefan Sperling wrote: On Mon, Sep 30, 2013 at 10:58:35AM +0300, Florin Avram wrote: Hi, I've found a strange behavior in the situation described below and wanted to let you know - I think there could be an issue or a need of improvement (don't know what exactly). Subversion: 1.8.x, 1.7.x. The situation is as follows (the minimum necessary to reproduce the issue): - have a working copy with a folder and a file inside the folder; - replace the folder and commit: svn delete folder/file svn delete --keep-local folder svn add folder (consider it as a new folder) svn commit folder (both folder and file) make new "file" inside folder svn add folder/file svn commit folder/file - now, in another working copy: svn status -u- reports folder as replaced and file as deleted svn update folder/file - svn indicates that file was updated fine svn statsus -u - again, both folder and file are reported as previously (replaced and deleted) Repeating the file update and "svn status" goes on and on as file updated correctly and file reported as deleted again. Only after updating the folder everything works fine. My question(s): - is this OK to happen like this? Yes, absolutely. The 'svn update folder/file' step creates a mixed-revision working copy (child is newer than its parent) and you then query the parent with 'status -u' so you get results for the parent, not the child. See http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
"svn delete" does not warn anymore in some cases
Hi, I noticed that SVN 1.8.5 does not give warnings for some situations, when using "svn delete" (previously, using SVN 1.7.x, it did): 1. have a file replaced with a directory in the working copy: - svn delete file - create new directory, with the same name as the file - svn add file (the directory; item is reported as replaced) - svn delete file - no warning. But, if trying to delete an added file, it warns. Shouldn't be something similar in this case, since replaced = deleted + added ?! 2. something similar if trying to delete such a file after being in tree-conflict: - do operations above, without the last one; - commit a file change from another working copy; - update - will give a tree-conflict; - try to delete the tree-conflict - no warning. 3. it seems that for items missing from the working copy (or, at least, for a few such situations I caught in my tests) there is no warning anymore. This I can understand, SVN makes the assumption that user deleted item without using the SVN client and "svn delete" is the natural way to end the operation. But, maybe the item was deleted unintentionally and the user wants to restore it if it knows that it is missing?! 4. Regarding #1, if having a directory being ADDED, there is no warning, only if the directory has something inside it (is not empty). This seems to be a general rule in SVN 1.8 - if there are added directories or items replaced with directories without content, they are deleted without warning. Are these changes intentional in SVN 1.8?! Any clarification/details about above situations is welcomed. Regards, Florin Avram
Re: "svn delete" does not warn anymore in some cases
On 04.02.2014 14:06, Philip Martin wrote: Stefan Sperling writes: On Tue, Feb 04, 2014 at 11:49:24AM +0200, Florin Avram wrote: Hi, I noticed that SVN 1.8.5 does not give warnings for some situations, when using "svn delete" (previously, using SVN 1.7.x, it did): 1. have a file replaced with a directory in the working copy: - svn delete file - create new directory, with the same name as the file - svn add file (the directory; item is reported as replaced) - svn delete file - no warning. But, if trying to delete an added file, it warns. Shouldn't be something similar in this case, since replaced = deleted + added ?! I cannot reproduce this. Can you please provide command sequences and their output instead of a verbal description? Below is what I did. It's file replaced by directory: svnadmin create repo --compatible-version 1.7 svn import -mm repo/format file://`pwd`/repo/A/f svn co file://`pwd`/repo wc svn rm wc/A/f svn mkdir wc/A/f svn rm wc/A/f with 1.8 the last rm succeeds, with 1.7 the last rm fails unless --force is used: svn: E195006: Use --force to override this restriction (local modifications may be lost) svn: E195006: '/tmp/wc/A/f' has local modifications -- commit or revert them first Some things still cause 1.8 to require force: setting properties on the directory or children, adding file children. Philip is right. I have some tests that worked with SVN 1.7.x, but they fail because the "svn delete" operation behaves differently with SVN 1.8.5 r1542147 compiled Nov 27 2013. What I saw from our tests, as a general SVN 1.8 behavior regarding "svn delete", is that it does not provide warnings (does not force you to use "--force" option anymore) in the below cases (there might be other cases I did not found): - for "added" directories, or items "replaced" with directories, if the directory has no properties set or has no content (other files, dirs inside); If there are items inside a deleted directory, the warning is not related with the deleted directory, but with an item inside it (with SVN 1.7, it said that the directory has changes). - for "missing" items (files or directories). So, my question is: is this SVN 1.8 "svn delete" behavior intentional or it should behave like with SVN 1.7 ?!
Re: "svn delete" does not warn anymore in some cases
On 04.02.2014 14:51, Philip Martin wrote: Florin Avram writes: So, my question is: is this SVN 1.8 "svn delete" behavior intentional or it should behave like with SVN 1.7 ?! It was a result of a deliberate change in r1442611 to allow the delete of unmodified copies without force: svn cp iota iota2 svn rm iota2 I think this does not answer completely to my question. If this was "a deliberate change to allow the delete of unmodified copies", should reported changes (missing warnings) be considered as a not desired side-effect of this change (and there should be open an issue to be solved), or this is the right "svn delete" behavior from now on (meaning it is correct to behave such, even if the items are not being copied)?
"svn revert" corrupts working copy
Hi, I found a situation when using "svn revert" seems to corrupt the working copy. In a working copy like this: - wc_root_dir -- directory --- file erase the directory from disk (not using SVN) and create a file with the same name instead. "svn status" will report: ~ directory ! directory/file Now, see the following sequence: svn revert directory/file svn: E155009: Failed to run the WC DB work queue associated with '/wc_root_dir/directory/file', work item 2 (file-install directory/file. 1 0 1 1) svn: E720087: Can't move '/wc_root_dir/.svn/tmp/svn-3884C5DC' to '/wc_root_dir/directory/file': The parameter is incorrect. svn status svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted svn cleanup Gives same message as "svn revert". svn --version svn, version 1.8.5 (r1542147) compiled Nov 27 2013, 04:10:18 on x86_64/x86-microsoft-windows5.1.2600 Regards, Florin Avram
Re: "svn revert" corrupts working copy
Well, this design corrupts the working copy and I cannot use it after. I
doubt this is what you want...
I ran into this issue by testing how "svn revert" behaves on different
strange situations, but, at least theoretically, anybody can run into it.
On 19.02.2014 13:02, Stefan Sperling wrote:
On Wed, Feb 19, 2014 at 12:50:02PM +0200, Florin Avram wrote:
Hi,
I found a situation when using "svn revert" seems to corrupt the working
copy. In a working copy like this:
- wc_root_dir
-- directory
--- file
erase the directory from disk (not using SVN) and create a file with the
same name instead.
"svn status" will report:
~ directory
! directory/file
Now, see the following sequence:
svn revert directory/file
svn: E155009: Failed to run the WC DB work queue associated with
'/wc_root_dir/directory/file', work item 2 (file-install directory/file. 1 0
1 1)
svn: E720087: Can't move '/wc_root_dir/.svn/tmp/svn-3884C5DC' to
'/wc_root_dir/directory/file': The parameter is incorrect.
Subversion is (correctly) trying to put a directory where you put a file.
Until the obstructing file is removed you'll get this error.
This is by design.
svn status
svn: E155037: Previous operation has not finished; run 'cleanup' if it was
interrupted
svn cleanup
Gives same message as "svn revert".
svn --version
svn, version 1.8.5 (r1542147)
compiled Nov 27 2013, 04:10:18 on x86_64/x86-microsoft-windows5.1.2600
Regards,
Florin Avram
Re: "svn revert" corrupts working copy
I think I know enough about Subversion and work with it for more than 5 years, so I know very well what obstructed and missing means, and that Subversion tries to not erase non-versioned data.I know only less about new SVN 1.8.x behavior, which I'm testing currently, and which in some situations is not to explicit and it does not help a common user (even if comparing it with older versions, many commands became powerful, especially with the new SVN 1.7 architecture). Not all users work with an SVN client or with the command-line client directlyand/or often- there are infinite use-cases and tools that work over a working copy non-aware of SVN. The client should help, as much as possible, the users to fix things when they switch from their development tool to SVN.And I say this from my experience, after interacting with many users that found themselves in the situation of not knowing what to do further at a given point, so any information pointing to the correct cause in solving any issue is essential.Users are error prone and may not have enough experience with Subversion - help them. I understand your point, but I have the feeling somewhere there is not a correct decision and things can be improved. What I'm trying to say is that what Subversion does in this case is not too obvious. Think to the following situation: - wc_root_dir -- dir1/file.txt -- dir2/file.txt Now, dir2 is obstructed and a user wants to revert dir1/file.txt. By mistake, he can type dir2/file.txt, so: - svn gives error and points to "svn cleanup" - the user tries "svn cleanup" and it does not work; - then, it tries "svn status" to see what are the states of the items, this way he can figure out if there is something wrong. It does not work also. The errors provided by Subversion do not point to the fact that there is an obstructed item and the obstructing item must be removed. What I reported previously was an information I already knew (the directory being obstructed), but given current situation, the user doesn't know that dir2 is obstructed (he wanted to work with dir1) and he cannot find out this using any Subversion client (since SVN givesa useless error). When the client states "The parameter is incorrect", this is useless information for a common user (it could be some library internal error?!).I remember that, in SVN 1.6.x, for some similar situations, there were some messages like"found a file instead of a versioned directory" or so - this is something useful, that points to the correct problem. But, as long as, in the given situation, the user cannot run "cleanup" or "status" to know more about what is happening, the next idea it has is that the working copy is corrupted and it needs to check out again. I agree with Philip Martin - before doing any changes to the working copy (and block it, from my point of view, after the example situation) it should do some checks and warn the user that the operation is not possible. This allows to work with the working copy further (runt other commands) and fix the issue. Regards, Florin On 19.02.2014 14:36, Stefan Sperling wrote: On Wed, Feb 19, 2014 at 12:17:06PM +, Philip Martin wrote: Stefan Sperling writes: So, just move your file to a safe place, and run 'svn revert' again. In this case it's 'svn cleanup' after removing the obstruction. Then I misunderstood the original problem report. Can you give me a reproduction recipe? Here's what I did: $ ls epsilon zeta $ rm -rf epsilon $ echo > epsilon $ svn st ~ epsilon ! epsilon/zeta $ svn revert epsilon/zeta svn: E155009: Failed to run the WC DB work queue associated with '/tmp/svn-sandbox/trunk/epsilon/zeta', work item 5 (file-install epsilon/zeta 1 0 1 1) svn: E20: Can't move '/tmp/svn-sandbox/trunk/.svn/tmp/svn-6SoBLy' to '/tmp/svn-sandbox/trunk/epsilon/zeta': Not a directory $ svn cleanup svn: E155009: Failed to run the WC DB work queue associated with '/tmp/svn-sandbox/trunk', work item 5 (file-install epsilon/zeta 1 0 1 1) svn: E20: Can't move '/tmp/svn-sandbox/trunk/.svn/tmp/svn-Sm3yxt' to '/tmp/svn-sandbox/trunk/epsilon/zeta': Not a directory $ mv epsilon outoftheway $ svn cleanup $ svn st ? outoftheway $ svn --version svn, version 1.8.5 (r1542147) compiled Jan 30 2014, 02:45:04 on x86_64-unknown-openbsd5.5
Re: "svn revert" corrupts working copy
I'm glad we found out a common point of view. A better error message, that indicates the cause (at least, in the provided example, it should be very clear what is triggering the error), would definitely help save some time, since no other command works to obtain other information about this working copy "blockage". Indeed, I work on Windows. Should I create a new issue regarding the error messages for this situation, or someone else does this?! On 19.02.2014 16:42, Stefan Sperling wrote: On Wed, Feb 19, 2014 at 02:52:48PM +0200, Florin Avram wrote: I understand your point, but I have the feeling somewhere there is not a correct decision and things can be improved. What I'm trying to say is that what Subversion does in this case is not too obvious. Think to the following situation: - wc_root_dir -- dir1/file.txt -- dir2/file.txt When the client states "The parameter is incorrect", this is useless information for a common user (it could be some library internal error?!). I agree here. The error messages that result from this problem are definitely not user friendly. This is not a new problem. Subversion has always had problems with many of its error messages being far from understandable for users :( I actually gave a conference talk on this very subject once, slides at http://www.elegosoft.com/files/Downloads/Subversion_Day_2011/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf In your case, "The parameter is incorrect" is most likely coming from the Windows operating system. I'm seeing "is not a directory" instead. I agree with Philip Martin - before doing any changes to the working copy (and block it, from my point of view, after the example situation) it should do some checks and warn the user that the operation is not possible. This allows to work with the working copy further (runt other commands) and fix the issue. Sometimes, it's hard to do such checks upfront, because we often don't know what problems can happen until they actually occur. Some operations can have way too many side effects to consider upfront, and checking upfront could hurt performance a lot in many cases. And if we're not very careful, such checks might actually end up breaking legitimate use cases that were overlooked when the checks were implemented. I think a better approach would be to try to systematically improve all error messages raised by the work queue subsystem in the working copy library, adding hints to the likely cause of the problem. I'd fully support a new entry in our issue tracker for such a task. Most of these messages are beyond what a normal user should have to deal with.
EXTERNALS remote status not reported
Hi,
For the following working copy structure:
- working_copy_root_dir
-- externalFileNORMAL(node status = normal)
-- externalFileMISSING (node status = missing)
-- externalFileOBSTRUCTED(node status = obstructed)
if I run:
cd working_copy_root_dir
svn status -u .
then, the out-of-date sign ('*') of the EXTERNAL files is not presented
(like using "--ignore-externals" option, but I'm not), although I
committed file content changes for the files to which those EXTERNALs
point, from another working copy.
Is this an intended behavior?! I tested with:
svn, version 1.8.5 (r1542147)
compiled Nov 27 2013, 04:10:18 on x86_64/x86-microsoft-windows5.1.2600
This behavior is consistent on both Windows and Linux.
Thanks,
Florin Avram
