PATCH: Update VCS_INFO_detect_svn for Subversion 1.7

PATCH: Update VCS_INFO_detect_svn for Subversion 1.7

[Akinori MUSHA]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Hi,

The attached patch fixes vcs_info not working under a subversion 1.7
working directory.

--
Akinori MUSHA / http://akinori.org/

Index: Functions/VCS_Info/Backends/VCS_INFO_detect_svn
===================================================================
RCS file: /cvsroot/zsh/zsh/Functions/VCS_Info/Backends/VCS_INFO_detect_svn,v
retrieving revision 1.3
diff -u -r1.3 VCS_INFO_detect_svn
--- Functions/VCS_Info/Backends/VCS_INFO_detect_svn	11 Feb 2011 07:05:09 -0000	1.3
+++ Functions/VCS_Info/Backends/VCS_INFO_detect_svn	9 Nov 2011 05:14:03 -0000
@@ -7,5 +7,5 @@
 [[ $1 == '--flavours' ]] && return 1

 VCS_INFO_check_com ${vcs_comm[cmd]} || return 1
-{ [[ -f ".svn/entries" ]] || [[ -f ".svn/format" ]] } && return 0
-return 1
+vcs_comm[detect_need_file]="entries format"
+VCS_INFO_bydir_detect '.svn' || return 1

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: PATCH: Update VCS_INFO_detect_svn for Subversion 1.7

[Frank Terbeck]

Akinori MUSHA wrote:
> The attached patch fixes vcs_info not working under a subversion 1.7
> working directory.
[...]
> -{ [[ -f ".svn/entries" ]] || [[ -f ".svn/format" ]] } && return 0
> -return 1
> +vcs_comm[detect_need_file]="entries format"
> +VCS_INFO_bydir_detect '.svn' || return 1

Oh yes, Subversion 1.7. If I understood things correctly, they put their
`.svn' sub-directory only into the root directory of the sandbox.

While the patch fixes detection for both 1.7 and before, we'll do the
same again (the directory traversal) in VCS_INFO_get_data_svn where the
system tries to find out, what the root directory of the sandbox is.
With 1.7 that won't be required, with 1.6 and before it is. So that
would be unnecessary work for 1.7.

I was kind of hoping to do this with a clever detection algorithm, which
would work for both versions and still reveal the sandbox's root
directory. So that we could scratch the root-retrieval from the
`_get_data_' function altogether.

The other way would be to look at "svn --version -q" and check if the
`_get_data_' function still needs to find the root directory. But I'd
actually like to avoid the additional `fork()'. (If you every tried
vcs_info on cygwin, you'll know what I mean.)

Ideas?

Regards, Frank

Re: PATCH: Update VCS_INFO_detect_svn for Subversion 1.7

[Frank Terbeck]

Frank Terbeck wrote:
[...]
> I was kind of hoping to do this with a clever detection algorithm, which
> would work for both versions and still reveal the sandbox's root
> directory. So that we could scratch the root-retrieval from the
> `_get_data_' function altogether.

I had an idea. How about abusing evaluated globbing for this?

local -a reply
reply=( (../)#.svn(/Ne@'[ ! -d "${REPLY:h}/../.svn" ] && { [ -f "${REPLY}/format" ] || [ -f "${REPLY}/entries" ]; }'@:A) )

Say whaaat?

Yeah, let me explain: When in a subversion sandbox, then `$reply' should
contain exactly *one* entry, and that's the full name of the sandbox's
root directory. If not, the `$reply' array should be empty.

How does it work? Well, the "(../)#.svn(/N)" pattern matches all .svn
sub-directories from the current directory up to the root directory `/'.

The ":A" at the end is responsible for turning relative paths into
absolute ones.

Now the fun is happening in the e@'...'@ expression. The "..." is shell
code that's evaluated with $REPLY set to all of the matching files from
the preceding glob. One file (or directory in this case) after another.

The "[ ! -d "${REPLY:h}/../.svn" ]" checks if there's a .svn directory
in the parent directory. If that's not the case, then we found the root
of the sandbox.

And then "{ [ -f "${REPLY}/format" ] || [ -f "${REPLY}/entries" ]; }" is
just the old test to make sure the `.svn' directory is really from a
sandbox and not from something else.

(If all the above was clear anyway, sorry for the long mail.)

I think this should work nicely for 1.7 and 1.6 (and before) without
causing doubled work.

Also, I think that most - if not all - calls to
`VCS_INFO_detect_by_dir()' could be replaced by a similar globbing
expression. That might improve performance. I don't know.

I'll come up with a patch for `VCS_INFO_detect_svn' later, unless
someone finds a flaw in the above idea.

Regards, Frank

Re: PATCH: Update VCS_INFO_detect_svn for Subversion 1.7

[Bart Schaefer]

On Nov 9,  2:58pm, Frank Terbeck wrote:
} Subject: Re: PATCH: Update VCS_INFO_detect_svn for Subversion 1.7
}
} How does it work? Well, the "(../)#.svn(/N)" pattern matches all .svn
} sub-directories from the current directory up to the root directory `/'.

I know it'd be a strange circumstance, but what happens if there is a
/.svn directory?  (Or /home/.svn, etc., somewhere above the user's
personal tree.)

Maybe qualify the glob with a U or G to check for user or at least
group ownership of the .svn directory?  Or would that break in some
other way?

Re: PATCH: Update VCS_INFO_detect_svn for Subversion 1.7

[Daniel Shahaf]

Bart Schaefer wrote on Wed, Nov 09, 2011 at 07:57:00 -0800:
> On Nov 9,  2:58pm, Frank Terbeck wrote:
> } Subject: Re: PATCH: Update VCS_INFO_detect_svn for Subversion 1.7
> }
> } How does it work? Well, the "(../)#.svn(/N)" pattern matches all .svn
> } sub-directories from the current directory up to the root directory `/'.
> 
> I know it'd be a strange circumstance, but what happens if there is a
> /.svn directory?  (Or /home/.svn, etc., somewhere above the user's
> personal tree.)
> 
> Maybe qualify the glob with a U or G to check for user or at least
> group ownership of the .svn directory?  Or would that break in some
> other way?

What if /etc/.svn exists, cwd is /etc/foo, and the user is editing
config files via sudo $EDITOR bar.conf ?

Re: PATCH: Update VCS_INFO_detect_svn for Subversion 1.7

[Jérémie Roquet]

Hi,

Still using my own version of VCS_INFO, but…

2011/11/9 Bart Schaefer <schaefer@brasslantern.com>:
> Maybe qualify the glob with a U or G to check for user or at least
> group ownership of the .svn directory?  Or would that break in some
> other way?

I'd really like to have vcs information even when in a directory I
don't own (but which I can read).

Best regards,

-- 
Jérémie

Re: PATCH: Update VCS_INFO_detect_svn for Subversion 1.7

[Frank Terbeck]

It seems like I was missing something Phil put into the `_get_data_'
function: It is able to handle nested working copies. As in: /foo/bar is
the checkout of one repository and /foo/bar/baz/bob being the checkout
of another.

My glob idea doesn't catch that properly.

The matter has been discussed on IRC for a while and I've come to the
conclusion that applying Akinori's original patch is probably the best.
It does double the work a little, but I think it should work in almost
all cases.

So, thanks for that.

Regards, Frank


Akinori MUSHA wrote:
[...]
> Index: Functions/VCS_Info/Backends/VCS_INFO_detect_svn
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Functions/VCS_Info/Backends/VCS_INFO_detect_svn,v
> retrieving revision 1.3
> diff -u -r1.3 VCS_INFO_detect_svn
> --- Functions/VCS_Info/Backends/VCS_INFO_detect_svn	11 Feb 2011 07:05:09 -0000	1.3
> +++ Functions/VCS_Info/Backends/VCS_INFO_detect_svn	9 Nov 2011 05:14:03 -0000
> @@ -7,5 +7,5 @@
>  [[ $1 == '--flavours' ]] && return 1
>
>  VCS_INFO_check_com ${vcs_comm[cmd]} || return 1
> -{ [[ -f ".svn/entries" ]] || [[ -f ".svn/format" ]] } && return 0
> -return 1
> +vcs_comm[detect_need_file]="entries format"
> +VCS_INFO_bydir_detect '.svn' || return 1