Re: invoke-diff-cmd branch is ready for trunk inclusion
Gabriela Gibson wrote: the latest invoke-diff-cmd branch: http://svn.apache.org/viewvc?view=revisionrevision=1538071 is ready to be merged into the trunk, iff everyone agrees that the current substitution syntax is just right and the documentation and the code itself is of acceptable standard. Hi Gabriela. It looks to me like this work is near complete. I have at last got around to reviewing it and I think there's only one significant thing to do before merging to trunk. Your BRANCH-README file http://svn.apache.org/repos/asf/subversion/branches/invoke-diff-cmd-feature/BRANCH-README is a fantastic window into the branch, much more detailed and helpful than the rest of us ever write. I can easily see exactly what the whole feature does, how it's structured, and what your plans are, without having been paying close attention. I'm mentioning this mainly so anybody else contemplating taking a look at this knows this is a good place to start reading. And I'm pleased to see you have taken care to adhere to our coding style. I'll mention my main two points first: 1. The interpolation/substitution syntax. 2. Duplication between --diff-cmd and --invoke-diff-cmd. and then a few coding-style and nit-picking trivia at the end. If at all possible, it would be convenient if the invoke-diff-cmd branch is not deleted quite yet, because I'm using a particular merge revision in that branch for testing the forthcoming invoke-merge-cmd feature. That's no problem. In fact, once we're happy, we'll ask you to do the merge into trunk. Although one would normally delete it at that time, you can keep the branch as long as you need to. === Interpolation/substitution Syntax === I said at the beginning of this exercise that we should leave the syntax issue till later, and now it is later. I tried a few things to see how the parsing handles things at the moment. One case that doesn't work right at the moment is this: $ svn diff subversion/svn/svn.c \ --invoke-diff-cmd 'echo %svn_old_label%,%svn_new_label%' which prints: subversion/svn/svn.c (revision 1536635),%svn_new_label% I also tried command strings involving %%, %%%, %svn_old_label%svn_new_label% and other variations to see if I could get it to output a plain '%' character when I wanted it and if it would substitute correctly in all combinations and so on. Basically I'm looking for the substitution syntax to (1) be regular, easy to predict the result, with a small number of easy-to-remember rules; (2) be possible to programatically 'escape' any arbitrary string X (even if it contains sequences like '%%' or '%old_label%' or anything that would otherwise have special meaning) to produce a result Y in such a way that putting Y through the substitution will recreate X exactly; and (3) be exactly the same syntax that we already use somewhere else in Subversion. So we need to follow up one of the suggestions that have been made about using the syntax from config files, or from user-defined keyword definitions, or something. I haven't paid close attention to those. If nobody else does, I'll see if I can make a concrete recommendation. Argument splitting: The function svn_io_run_external_diff() is now the main entry point for running a diff command, and you have made the old svn_io_run_diff2() into a wrapper which forwards to svn_io_run_external_diff(). That's fine in principle. However, there is a reason the old one took its arguments as an array rather than as a space-separated string. Parsing a space-separated string into a list of arguments is hard to get right in terms of syntax design and in terms of implementation, when it comes to the edge cases involving spaces in arguments, zero-length arguments and so on. So avoid it. Don't join the arguments into a single string, keep them as an array all the way through the system. === Duplication === It would be nice if we could find a way to duplicate less of the settings and the implementation: instead of --diff-cmd and --invoke-diff-cmd being handled by two separate options, variables, code paths, etc, could we reduce them to sharing a single implementation at some level in the code? If so, it would lead to a number of simplifications. In subversion/libsvn_client/diff.c: + if (diff_cmd_baton-diff_cmd diff_cmd_baton-invoke_diff_cmd) + return svn_error_create(SVN_ERR_CLIENT_DIFF_CMD, NULL, The need for this error might go away entirely. In set_up_diff_cmd_and_options(): Not sure about the precedence of old and new options. And instead of keeping them in separate variables, can we combine them? In subversion/include/svn_io.h and subversion/libsvn_subr/io.c: svn_io_run_external_diff() is very similar to svn_io_run_diff2(), and I think it makes sense to make its interface even more similar and then keep only the newer one, deprecating the older one. Choose one style: either have the caller do the argument interpolation before calling it, and pass
RE: svn commit: r1539407 - in /subversion/trunk/subversion/bindings/javahl: native/ native/jniwrapper/ src/org/apache/subversion/javahl/types/ tests/org/apache/subversion/javahl/
-Original Message-
From: br...@apache.org [mailto:br...@apache.org]
Sent: woensdag 6 november 2013 18:34
To: comm...@subversion.apache.org
Subject: svn commit: r1539407 - in
/subversion/trunk/subversion/bindings/javahl: native/ native/jniwrapper/
src/org/apache/subversion/javahl/types/
tests/org/apache/subversion/javahl/
Author: brane
Date: Wed Nov 6 17:34:08 2013
New Revision: 1539407
URL: http://svn.apache.org/r1539407
Log:
Added a test case for the JavaHL svn:externals parser, consequently
uncovering a couple of nasty bugs and a silly thinko.
[in subversion/bindings/javahl]
* native/ExternalItem.cpp
(make_external_item): Send the correct number of parameters to
the private ExternalItem constructor.
* native/jniwrapper/jni_array.hpp
(ByteArray::data):
Add a note to the docstring that the result will not be NUL-terminated.
(ByteArray::get_string): Reimplement so that it copies the data to a pool
and properly NUL-terminates it, so that it can be used as a C string.
* native/org_apache_subversion_javahl_util_PropLib.cpp
(operator==, operator!=): Comparison operators for svn_opt_revision_t.
(Java_org_apache_subversion_javahl_util_PropLib_parseExternals):
Scope the String and ByteArray contents accessors so that they can be
made
constant, i.e., immutable as per spec.
Make a NUL-terminated copy of the array contents before using them.
(Java_org_apache_subversion_javahl_util_PropLib_unparseExternals):
Do not generate the -rN option if the revision and peg are the same.
Likewise do not barf on a non-HEAD peg revision oldstyle mode.
Scope the String contents accessor to make it constant.
* src/org/apache/subversion/javahl/types/ExternalItem.java
(ExternalItem.ExternalItem): Default a null revision to the peg revision
value instead of HEAD, and update the docstring.
(ExternalItem.equals): New; equality checker.
* tests/org/apache/subversion/javahl/UtilTests.java
(externals): Add 5 more cases to cover ExternalItem changes.
(old_externals): Swap revision and peg parameters.
(externals_propval, old_externals_propval): New.
(compare_item_lists): New.
(testParseExternals): New test case.
(testUnparseExternals): Check result against externals_propval.
(testUnparseExternalsOldstyle): Check result against
old_externals_propval.
Modified:
subversion/trunk/subversion/bindings/javahl/native/ExternalItem.cpp
subversion/trunk/subversion/bindings/javahl/native/jniwrapper/jni_array.h
pp
subversion/trunk/subversion/bindings/javahl/native/org_apache_subversio
n_javahl_util_PropLib.cpp
subversion/trunk/subversion/bindings/javahl/src/org/apache/subversion/ja
vahl/types/ExternalItem.java
subversion/trunk/subversion/bindings/javahl/tests/org/apache/subversion/
javahl/UtilTests.java
Modified:
subversion/trunk/subversion/bindings/javahl/native/ExternalItem.cpp
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/bindings/javahl
/native/ExternalItem.cpp?rev=1539407r1=1539406r2=1539407view=diff
==
--- subversion/trunk/subversion/bindings/javahl/native/ExternalItem.cpp
(original)
+++ subversion/trunk/subversion/bindings/javahl/native/ExternalItem.cpp
Wed Nov 6 17:34:08 2013
@@ -62,7 +62,7 @@ jobject make_external_item(::Java::Env e
(ZLjava/lang/String;Ljava/lang/String;
LJAVA_PACKAGE/types/Revision;
LJAVA_PACKAGE/types/Revision;)V);
- return env.NewObject(cls, mid_ctor,
+ return env.NewObject(cls, mid_ctor, JNI_FALSE,
env.NewStringUTF(target_dir),
env.NewStringUTF(url),
Revision::makeJRevision(*revision),
Modified:
subversion/trunk/subversion/bindings/javahl/native/jniwrapper/jni_array.h
pp
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/bindings/javahl
/native/jniwrapper/jni_array.hpp?rev=1539407r1=1539406r2=1539407vi
ew=diff
==
---
subversion/trunk/subversion/bindings/javahl/native/jniwrapper/jni_array.h
pp (original)
+++
subversion/trunk/subversion/bindings/javahl/native/jniwrapper/jni_array.h
pp Wed Nov 6 17:34:08 2013
@@ -30,6 +30,7 @@
#include svn_string.h
#include jni_env.hpp
+#include ../Pool.h
namespace Java {
@@ -164,6 +165,7 @@ public:
/**
* Returns the address of the array contents.
+ * @note The data will @b not be NUL-terminated!
* @throw std::logic_error if the data reference is immutable.
*/
char* data()
@@ -183,12 +185,13 @@ public:
}
/**
- * Constructs @a str that refers to the array contents.
+ * Copies the array contents to a NUL-terminated string allocated
+ * from @a result_pool.
*/
-void get_string(svn_string_t* str)
Re: invoke-diff-cmd branch is ready for trunk inclusion
On Wed, Nov 6, 2013 at 3:12 PM, Julian Foad julianf...@btopenworld.com wrote: Gabriela Gibson wrote: Hi Julian and everyone, thank you for the thorough review, the revision with the fixes can be seen here: http://svn.apache.org/r1539448 the latest invoke-diff-cmd branch: http://svn.apache.org/viewvc?view=revisionrevision=1538071 is ready to be merged into the trunk, iff everyone agrees that the current substitution syntax is just right and the documentation and the code itself is of acceptable standard. Hi Gabriela. It looks to me like this work is near complete. I have at last got around to reviewing it and I think there's only one significant thing to do before merging to trunk. Your BRANCH-README file http://svn.apache.org/repos/asf/subversion/branches/invoke-diff-cmd-feature/BRANCH-README is a fantastic window into the branch, much more detailed and helpful than the rest of us ever write. I can easily see exactly what the whole feature does, how it's structured, and what your plans are, without having been paying close attention. I'm mentioning this mainly so anybody else contemplating taking a look at this knows this is a good place to start reading. And I'm pleased to see you have taken care to adhere to our coding style. Thank you very much for the compliments! === Interpolation/substitution Syntax === I said at the beginning of this exercise that we should leave the syntax issue till later, and now it is later. :) I also tried command strings involving %%, %%%, %svn_old_label%svn_new_label% and other variations to see if I could get it to output a plain '%' character when I wanted it and if it would substitute correctly in all combinations and so on. Basically I'm looking for the substitution syntax to (1) be regular, easy to predict the result, with a small number of easy-to-remember rules; (2) be possible to programatically 'escape' any arbitrary string X (even if it contains sequences like '%%' or '%old_label%' or anything that would otherwise have special meaning) to produce a result Y in such a way that putting Y through the substitution will recreate X exactly; and (3) be exactly the same syntax that we already use somewhere else in Subversion. I've taken the entire interpolation mechanism out, completely. Here is why: 1) the apr function called is set to not be a shell, but passes the arguments directly to the called program. 2) we not longer use commonly used variable name, such as 'f1' 'l1' etc, which users may want to preserve for their own purposes, which was the original reason for wanting the interpolation ability. 3) After some thinking about this, I figured that whilst interpolation is fine on the command line, if we were to add individual --invoke-diff-cmd entries to the props (before I discarded that idea in favor of the --cfg-file idea) the interpolation would end up being an implicit magic number in form of '%%%'s. Since we cannot know who uses this repository, I was wondering what happens if two+ teams in maybe different companies use the same repository, and when someone changes the prop command, a lot of unintended breakage down the chain may ensue, or it ends up locking users into a pattern one person decided that may not be useful for others. Hence the idea for the files and I then realized that we can keep it simple and do not need to interpolate at all. We now simply reserve 10 keyword that start with '%svn_' and parse those out when we see them, and users will just have to be creative in their variable name choice. That may not be a good approach but it sure is simple. I unfortunately omitted to document this properly, but have done so now. The reserved keywords are: Diff(4): %svn_old %svn_label_old %svn_new %svn_label_new Merge(6): %svn_mine %svn_label_mine %svn_yours %svn_label_yours %svn_base %svn_label_base. 'label' is placed before the descriptor because this way we can avoid needing a closing delimiter, otherwise, %svn_old_label will get misparsed as /file/foo.c_label. 4) Users can use interpolation with any of their private variables, ie, %f1 or f1 is all no problem, but we do not touch those strings at all, but simply copy them 'as is'. I can however add code to eat the first % of such constructs, but it will be just be 'for show' :-) Users might find this behavior less confusing, but there is also point 3) to consider. Whatever you like as your favorite diff program may not be the next man's choice, which is why I was lobbying to have the option of arbitrary diff-config files instead of using ~/.subversion/config or per-file props that apply globally to every user. That said, %%svn_old will currently turn into %/tmp/file/name, because we also cater for constructs like +%svn_old to make +/tmp/file/name. Then again, the freedom to do almost everything you like includes the freedom to make
follow symlinks
Hello, after going full retard in IRC (it was good for me) I have calmed down enough to give constructive criticism in regards of subversion and how it handles symbolic links on Unix (and compat.) platforms. I wan't to start with a question. I am confident there is no answer to it. At least not from people who share code between projects. * Why does subversion store symbolic links instead of following them? * I really don't get it. Who has a symbolic link inside a codebase pointing to another place inside the same codebase? That. And only that would justify the way how subversion handles symbolic links. It is in my 20 years experience with Unix, code and CVS and subversion much, /much/ more likely you use symlinks to point to code that is shared between multiple repositories. So it would be intuitive and conform to operating system standards if subversion would follow these instead of storing the actual symlinks and, by that, potentially cause a loss of precious work in an update in another local copy. So it was suggested to do it the subversion way. I can only assume that subversion reinvents the usability of symlinks in it's own murky/un-intuitive/proprietary way because of alternative operating systems like windows that have nothing like symlinks. (I am sure there will be a enthusiast trying to convince me that subversion does it better than the symlinks i used the last 15 years. - It doesn't.) So subversion has been developed for more than a decade now and nobody thought about adding --enable-follow-symlinks or something similar to the configure script. Fine. I can do it myself. So I did just remove the #define HAVE_SYMLINKS from the config and build it myself. Only to end up with a client who /still/ recognizes symbolic links and refuses to follow them. Tonight I found out that subversion also has a problem when I just use mount --bind to share code between projects. I thought I could do that after the .svn was centralized in the root of the project. But no. Subversion doesn't like that. Another Problem I have with subversion is that everything is stored in binary files. It is not like that I damage my repositories all the time. It happens maybe once every couple of years. But when it happens there is nothing else to do that to start a new repository with whatever is left in the local copy. I'd like to point out that CVS can, under any circumstance, be fixed with a standard text editor. I just never had it that I has to reimport a CVS repository to fix a broken one. I really wonder what the advantages of subversion are except from that TortoiseSVN is more actively developed than TortoiseCVS whose developers seem to have a irrational aversion against switching from XP to Win7. Win7 is ok for a Windows. So. Despite knowing that some narcissistic project herald will announce to my face that It is impossible. Because it doesn't flow with out vision. I would like ask you to include a compile option in the configure script that makes subversion follow symlinks. Just for (the majority of) us developers who have no use for symbolic links instead of the actual files in their repository. The package maintainers shall continue ignoring that little feature. That way subversion would embrace something that made Linux great: Choice. Thank you, Dirk
Re: follow symlinks
On Wed, Nov 6, 2013 at 4:49 PM, Dirk noi...@pwnoogle.com wrote: after going full retard in IRC (it was good for me) I have calmed down enough to give constructive criticism in regards of subversion and how it handles symbolic links on Unix (and compat.) platforms. I wan't to start with a question. I am confident there is no answer to it. At least not from people who share code between projects. * Why does subversion store symbolic links instead of following them? * Here is the original thread when the feature was added, I would assume this was discussed but I suppose it might have happened prior to the patch being submitted (did not read the entire thread): http://svn.haxx.se/dev/archive-2004-06/0986.shtml -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: follow symlinks
On Wed, Nov 06, 2013 at 04:58:48PM -0500, Mark Phippard wrote: Here is the original thread when the feature was added, I would assume this was discussed but I suppose it might have happened prior to the patch being submitted (did not read the entire thread): http://svn.haxx.se/dev/archive-2004-06/0986.shtml It's well worth reading :) [[[ Of course, every engineer always claims that they're arguing for simplicity, directness, and elegance. So when I claim that I'm arguing here for simplicity, directness, and elegance, please understand that it's only because I'm on the side of goodness, truth, and beauty. -Karl ]]]
Re: follow symlinks
On 11/06/13 22:58, Mark Phippard wrote: On Wed, Nov 6, 2013 at 4:49 PM, Dirk noi...@pwnoogle.com wrote: after going full retard in IRC (it was good for me) I have calmed down enough to give constructive criticism in regards of subversion and how it handles symbolic links on Unix (and compat.) platforms. I wan't to start with a question. I am confident there is no answer to it. At least not from people who share code between projects. * Why does subversion store symbolic links instead of following them? * Here is the original thread when the feature was added, I would assume this was discussed but I suppose it might have happened prior to the patch being submitted (did not read the entire thread): http://svn.haxx.se/dev/archive-2004-06/0986.shtml Yes. That seems to be the patch that makes subversion store symbolic links (and other special files) in the repository instead of following them. It doesn't make a lot of sense. These special files are platform depending and there is no point in having them in /any/ repository. Even if it is a project that is only for a single platform it doesn't make sense storing special files in the repository. Symlinks, device files, etc. are most likely worthless on another machine. It is customary to create them during or at the end of a building process. They translate poorly from one setup to another. But that is how subversion behaves and how people know it to behave. So I repeat asking for a /option/ in the configure script to make subversion follow symlinks instead of storing these special files. I don't want so rain into the svn:externals parade. But symlinks are just more intuitive for people familar to Unix and it shows: https://www.google.com/search?q=subversion+follow+symlinks Thanks, Dirk
Re: follow symlinks
On 11/06/13 22:58, Mark Phippard wrote: On Wed, Nov 6, 2013 at 4:49 PM, Dirk noi...@pwnoogle.com wrote: after going full retard in IRC (it was good for me) I have calmed down enough to give constructive criticism in regards of subversion and how it handles symbolic links on Unix (and compat.) platforms. I wan't to start with a question. I am confident there is no answer to it. At least not from people who share code between projects. * Why does subversion store symbolic links instead of following them? * Here is the original thread when the feature was added, I would assume this was discussed but I suppose it might have happened prior to the patch being submitted (did not read the entire thread): http://svn.haxx.se/dev/archive-2004-06/0986.shtml That thread is terrible. The last sentence of this: http://svn.haxx.se/dev/archive-2004-06/1014.shtml is the last rational thing to be read. Then the thread takes off in a overengineering-fueled rant between people how to implement this and how further awesome increases in complexity are necessary to do so. And somehow it was committed at some later point and /nobody/ cares to write how happy he/she is with that change. It is like only casual programmers were part of that decision making. People who have maybe one project and do not recognize how pointless it is to store special files like symbolic links instead of following them to the actual file. Thanks, Dirk
Re: follow symlinks
[Dirk] It doesn't make a lot of sense. These special files are platform depending and there is no point in having them in /any/ repository. Even if it is a project that is only for a single platform it doesn't make sense storing special files in the repository. Symlinks, device files, etc. are most likely worthless on another machine. I question both assertions: that symlinks are platform-dependent, and that it is not useful to be able to store them. First, they are platform dependent only in an extremely broad sense. According to APUE, symlinks were introduced in 4.2BSD and subsquently supported by SVR4. That's almost 25 years ago, about the same range of Unix variants where filenames can be longer than 14 bytes. (Remember that annoying 14-byte filename limit in Unix? Me neither.) Heck, even Windows Server has symlinks these days. Granted, they're kinda weird (with 2 distinct types, file links and dir links, and it seems 'mklink' requires administrative access). But they do exist. But the second and more important part of your argument is that there's no valid use case for symlinks in a repository. And there I think you're conflating relative links and absolute links. Absolute links, as you say, are often rather specific to one host or one OS. But relative links, links _within the checkout_, aren't at all. I've used them. Couldn't I have just written a script or Makefile to generate and delete them? Sure, but by that argument I could put uuencode and uudecode into a script, and never need the ability to store non-text files in svn.
Re: follow symlinks
On 11/6/13 1:49 PM, Dirk wrote: after going full retard in IRC (it was good for me) I have calmed down enough to give constructive criticism in regards of subversion and how it handles symbolic links on Unix (and compat.) platforms. First of all this really belongs on the users@ list and not dev@. But it's here now so let's look at what your issues are... I wan't to start with a question. I am confident there is no answer to it. At least not from people who share code between projects. * Why does subversion store symbolic links instead of following them? * It would be a lot more likely for you to get a better response if you actually explained what you were trying to do. What use case(s) did you run into where how we're behaving are problematic. What version of Subversion were you using that presented problems? It's possible this is a bug, in fact quite a few issues have cropped up with this sort of thing due to the change from WC to WCNG that happened in 1.7.x. Since I don't have any sense of what you were actually trying to do... Let's just talk a bit about what Subversion does right now (including some places that are probably a step back from earlier versions) with trunk (though nothing mentioned here should have significantly changed since 1.8.4). [[[ $ svnadmin create repo $ svn co file://`pwd`/repo wc Checked out revision 0. $ ln -s wc wc-link $ svn info wc Path: wc Working Copy Root Path: /Users/breser/symlinks/wc URL: file:///Users/breser/symlinks/repo Relative URL: ^/ Repository Root: file:///Users/breser/symlinks/repo Repository UUID: ae7752ff-322b-45e2-ba88-c74efb4e3747 Revision: 0 Node Kind: directory Schedule: normal Last Changed Rev: 0 Last Changed Date: 2013-11-06 15:36:27 -0800 (Wed, 06 Nov 2013) $ svn info wc-link Path: wc-link Working Copy Root Path: /Users/breser/symlinks/wc-link URL: file:///Users/breser/symlinks/repo Relative URL: ^/ Repository Root: file:///Users/breser/symlinks/repo Repository UUID: ae7752ff-322b-45e2-ba88-c74efb4e3747 Revision: 0 Node Kind: directory Schedule: normal Last Changed Rev: 0 Last Changed Date: 2013-11-06 15:36:27 -0800 (Wed, 06 Nov 2013) $ cd wc $ echo foo foo $ svn add foo A foo $ svn ci -mm Adding foo Transmitting file data . Committed revision 1. ]]] So far so good, my linked path to the working copy followed the symlink and gave me info about the wc I was looking at. I've got a new file that I've added. [[[ $ ln -s foo bar $ svn ci -mm Adding bar Transmitting file data . Committed revision 2. $ svn pl -v bar Properties on 'bar': svn:special * $ svn cat bar link foo ]]] Okay so now Subversion stored a link when I `svn add`ed a link. I don't think this is too spectacularly unexpected. I told it to add a symlink. Let's continue looking at the behavior that Subversion has with symlinks though. [[[ $ svn mkdir dir A dir $ cd dir $ echo alpha alpha $ svn add alpha A alpha $ svn ci -mm Adding . Adding alpha Transmitting file data . Committed revision 3. $ cd ../.. $ ln -s wc/dir dir-link $ svn info dir-link Path: dir-link Working Copy Root Path: /Users/breser/symlinks/wc URL: file:///Users/breser/symlinks/repo/dir Relative URL: ^/dir Repository Root: file:///Users/breser/symlinks/repo Repository UUID: ae7752ff-322b-45e2-ba88-c74efb4e3747 Revision: 3 Node Kind: directory Schedule: normal Last Changed Author: breser Last Changed Rev: 3 Last Changed Date: 2013-11-06 15:49:34 -0800 (Wed, 06 Nov 2013) $ echo one dir-link/alpha $ svn status dir-link/alpha svn: warning: apr_err=SVN_ERR_WC_NOT_WORKING_COPY svn: warning: W155007: '/Users/breser/symlinks/dir-link/alpha' is not a working copy $ svn commit dir-link/alpha /Users/breser/wandisco/share/wcs/svn-trunk/subversion/svn/commit-cmd.c:182, /Users/breser/wandisco/share/wcs/svn-trunk/subversion/libsvn_client/commit.c:648, /Users/breser/wandisco/share/wcs/svn-trunk/subversion/libsvn_client/commit.c:372, /Users/breser/wandisco/share/wcs/svn-trunk/subversion/libsvn_wc/wc_db.c:1615, /Users/breser/wandisco/share/wcs/svn-trunk/subversion/libsvn_wc/wc_db_wcroot.c:626: (apr_err=SVN_ERR_WC_NOT_WORKING_COPY) svn: E155007: '/Users/breser/symlinks/dir-link/alpha' is not a working copy $ svn status wc/dir/alpha M wc/dir/alpha $ svn commit wc/dir/alpha -mm Sendingwc/dir/alpha Transmitting file data . Committed revision 4. ]]] So now we made a directory inside our working copy and added a file. We went up outside our working copy and made a symlink into it. We then tried to run a status using the symbolic link in target, which failed. We then tried to commit the file using the same link as the status and that fails again. Using the real path without the symlink and it works fine. So now let's try the same thing with 1.6: [[[ $ mkdir 1.6 $ cd 1.6 $ svnadmin-1.6 create repo $ svn-1.6 co file://`pwd`/repo wc Checked out revision 0. $ cd wc $ svn mkdir dir A dir $ echo 'alpha'
Re: follow symlinks
On 07.11.2013 01:47, Ben Reser wrote: I think you're going to need to be a lot more specific about what you're doing if you disagree. And perhaps just a teensy bit less certain that only your opinion can be correct. It's rather hard to have a technical discussion based on a bunch of vague and uninformed flames. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
svn: E000005: Can't check path '/net/.svn': Input/output error
Using a MacPorts build of svn 1.8.4 on a 10.7.5 MacBook Air: $ uname -a Darwin foo.example.com 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 i386 MacBookAir4,2 Darwin $ cd /net/yum/blair $ mkdir tmp $ svn checkout -N http://svn.apache.org/repos/asf/subversion/trunk svn: E05: Can't check path '/net/.svn': Input/output error This looks related to NFS, as the MacBook Air will mount our NFS volumes: $ cat /etc/auto_master # # Automounter master map # /net/etc/auto.spi /hosts /etc/auto.net /etc/auto.spi is a long shell script that does an LDAP lookup on the proper server to mount and mount options to use. It looks like /etc/auto.spi does an 'exit 1' when the LDAP lookup for '.svn' fails. $ /etc/auto.spi yum -intr,soft,nodev,vers=3,tcp,bg\ foobar:/foo/vol0/yum $ echo $? 0 $ /etc/auto.spi .svn $ echo $? 1 Any ideas on how to best resolve this? Blair
Re: svn: E000005: Can't check path '/net/.svn': Input/output error
On 11/6/13 5:15 PM, Blair Zajac wrote: Using a MacPorts build of svn 1.8.4 on a 10.7.5 MacBook Air: $ uname -a Darwin foo.example.com 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 i386 MacBookAir4,2 Darwin $ cd /net/yum/blair $ mkdir tmp $ svn checkout -N http://svn.apache.org/repos/asf/subversion/trunk svn: E05: Can't check path '/net/.svn': Input/output error This looks related to NFS, as the MacBook Air will mount our NFS volumes: $ cat /etc/auto_master # # Automounter master map # /net/etc/auto.spi /hosts/etc/auto.net /etc/auto.spi is a long shell script that does an LDAP lookup on the proper server to mount and mount options to use. It looks like /etc/auto.spi does an 'exit 1' when the LDAP lookup for '.svn' fails. $ /etc/auto.spi yum -intr,soft,nodev,vers=3,tcp,bg\ foobar:/foo/vol0/yum $ echo $? 0 $ /etc/auto.spi .svn $ echo $? 1 Any ideas on how to best resolve this? I think you should talk to whoever wrote auto.spi. For what it's worth I use working copies on NFS as well (also on a MacBook Air with 10.7.5), however I mount them with the automatic NFS mounts feature of the Disk Utility application. I haven't had any issues doing this. It's not clear if you think there is a Subversion specific issue here but I don't see what it is if you do.
Re: svn: E000005: Can't check path '/net/.svn': Input/output error
On 11/06/2013 05:54 PM, Ben Reser wrote: On 11/6/13 5:15 PM, Blair Zajac wrote: Using a MacPorts build of svn 1.8.4 on a 10.7.5 MacBook Air: $ uname -a Darwin foo.example.com 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 i386 MacBookAir4,2 Darwin $ cd /net/yum/blair $ mkdir tmp $ svn checkout -N http://svn.apache.org/repos/asf/subversion/trunk svn: E05: Can't check path '/net/.svn': Input/output error This looks related to NFS, as the MacBook Air will mount our NFS volumes: $ cat /etc/auto_master # # Automounter master map # /net/etc/auto.spi /hosts/etc/auto.net /etc/auto.spi is a long shell script that does an LDAP lookup on the proper server to mount and mount options to use. It looks like /etc/auto.spi does an 'exit 1' when the LDAP lookup for '.svn' fails. $ /etc/auto.spi yum -intr,soft,nodev,vers=3,tcp,bg\ foobar:/foo/vol0/yum $ echo $? 0 $ /etc/auto.spi .svn $ echo $? 1 Any ideas on how to best resolve this? I think you should talk to whoever wrote auto.spi. For what it's worth I use working copies on NFS as well (also on a MacBook Air with 10.7.5), however I mount them with the automatic NFS mounts feature of the Disk Utility application. I haven't had any issues doing this. We have large numbers of different volumes with mount points coming and going and hundreds of MacBook Airs, so the LDAP approach lets us centralize this. It's not clear if you think there is a Subversion specific issue here but I don't see what it is if you do. I'm wondering if its a regression with older versions of Subversion as it walks up the tree to find a .svn directory. Blair
Re: svn: E000005: Can't check path '/net/.svn': Input/output error
On 11/6/13 6:21 PM, Blair Zajac wrote: I'm wondering if its a regression with older versions of Subversion as it walks up the tree to find a .svn directory. Well the error is coming from io_check_path() in subversion/libsvn_subr/io.c. Specifically we run apr_stat() on the path and are expecting a valid status or something that is true when passed to APR_STATUS_IS_ENOENT() or SVN__APR_STATUS_IS_ENOTDIR(). apr_stat of course is just a thing wrapper around lstat() or stat(). In your case based on the error message it's returning 5 which according to /usr/include/sys/errno.h is EIO. And of course Subversion is saying there's an Input/output error consistent with the error code it received. Unfortunately the documentation for this is hardly clear (see man auto_master under Executable Map). It says that you should exit with a non zero exit code and no output if there is an error. Their example even shows it exiting with `exit 1` when the Open Directory query returned no results. Based on some simple experimentation I added the following to my /etc/auto_master file: /nxx/etc/auto.nxx Added a /etc/auto.nxx file containing [[[ #!/bin/sh exit 1 ]]] Made /etc/auto.nxx executable and ran `automount -vc` to activate it. Then I ran this: $ ls -l /nxx/x ls: /nxx/x: Input/output error Changing the exit code to 0 in /etc/auto.nxx I then repeated the ls command and got: $ ls -l /nxx/x ls: /nxx/x: No such file or directory So it seems to me that unless the commands to query LDAP fail that your script should exit with zero exit code and no output to indicate there is no such mount point. So like I said before it seems to me that this is a bug in your /etc/auto.spi
