error on SVN upgrade working copy when repository has been relocated
The error message has been reported previously, but I did not see that the problem has been resolved: (I had to type by hand as cp did not work) --- Subversion Exception! --- (snip) Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.6\ext\subversion\subversion\libsvn_wc\util.c' line 300: assertion failed (svn_uri_is_canonical(repos_url, pool) svn_relpath_is_canonical(path_in_repos) SVN_IS_VALID_REVNUM(peg_rev)) What I was doing: I did SVN upgrade working copy from version 1.6 to 1.7. Since my last update the svn repository has been relocated to a new url. (I haven't used the rep on this computer for quite some time.) Could that be the cause? I could reproduce the error with a different folder of the same rep, so it was also relocated. Immediately before, I have upgraded a different working copy of a different folder without error. The rep is the same (so it has also moved), but it might be that I had already relocated the rep with a 1.6-subversion (sorry that I do not remember for sure). OS: Windows 7 Home Premium Suversion id: TortoiseSVN 1.7.6, Build 22632 - 64 Bit , 2012/03/08 18:29:39 Subversion 1.7.4, apr 1.4.5 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.0g 18 Jan 2012 zlib 1.2.5
[PATCH] bash URL completion
Hi everyone,
I strongly felt the urge to have some way of bash-completing URLS from
the command line when doing checkouts, listing, cat (for README/REVNOTES
files) and so on...
I looked up the tools/client-side/bash_completion script only to
realize it works for local (file:///) but not remote URLs.
So I came up with the attached patch, which works for me (tested with
bash 4.1.2, svn 1.6.11)
The idea was (apart from adding sub-dir completion with a gross svn ls
command) to (manually) list known repositories within a ~/.svn_repos
file, one per line:
http://srv1/proj1
svn://srv2/proj2
The reason behind this is that data cached in
~/.subversion/auth/svn.simple does not contain the full project URL
(only the server name) and I could not find a way to get that
information anywhere else.
I known it would've made more sense to ask for advice *BEFORE* touching
the code, but still... :-)
Thanks in advance for your feedback!
Gerlando
P.S. I'm not subscribed to the list, so please Cc: me, thanks!
diff --git a/svn-completion.bash b/svn-completion.bash
index 12285f4..c2684b3 100644
--- a/svn-completion.bash
+++ b/svn-completion.bash
@@ -35,6 +35,12 @@
shopt -s extglob
+function _debug()
+{
+ # echo $@ /tmp/svn-completion.debug
+ true
+}
+
# Tree helper functions which only use bash, to ease readability.
# look for value associated to key from stdin in K/V hash file format
@@ -112,6 +118,53 @@ function _svn_lls()
done
}
+# _svn_remotels currUrl proto
+# e.g. currUrl = //server/project/dirprefix
+# proto = http:
+# list svn files/dirs (using svn ls) from a given path
+# NOTE: this function outputs full URLs (except the protocol part), like
+# //srv/proj/branches/ //srv/proj/tags/ //srv/proj/trunk/
+function _svn_remotels()
+{
+local currUrl=$1
+local proto=$2
+
+local fullUrl=$2$1
+_debug Trying to complete $opt
+
+# HACK: fullUrl is something like http://srv/proj/ or http://srv/proj/ta
+# so we add an X and get the dirname from there in order to see where we
+# should run svn ls against (that is, http://srv/proj)
+local urlDir=$(dirname ${fullUrl}X)/
+
+# now get the prefix part of the file (e.g. ta for target.def)
+# (this is used for local filtering)
+local filepref=${fullUrl#${urlDir}}
+
+# This output prefix //srv/proj/ will be re-added to the individual ls
entries
+# so to get something like a full path listing (except leading
protocol:)
+local outurlDir=${urlDir#${proto}}
+
+_debug prefix to be matched is $filepref
+
+local files=()
+local f=
+svn ls --non-interactive $urlDir /dev/null 2/dev/null | while IFS= read
-r f
+do
+ _debug -n ... $f:
+ # if the filename matches the provided string, add it to the list
+ if [[ -z $filepref || $f == $filepref* ]]
+ then
+ _debug YES
+echo $outurlDir$f
+else
+ _debug NO
+ fi
+done
+
+return 0
+}
+
# This completion guides the command/option order along the one suggested
# by svn help, although other syntaxes are allowed.
#
@@ -395,9 +448,22 @@ _svn()
fi
# URL completion
- if [[ $cmd == @(co|checkout|ls|list) $stat = 'arg' \
+ if [[ $cmd == @(co|checkout|ls|list|cat) $stat = 'arg' \
$SVN_BASH_COMPL_EXT == *urls* ]]
then
+ # whenever a colon (:) is present, bash will split it into
three different parts:
+ # 1) http
+ # 2) :
+ # 3) //full/path/to
+ # So we need to reconstruct this
+ #FIXME this should be made more robust
+
+ local prefixUrl=${COMP_WORDS[i-3]}${COMP_WORDS[i-2]}#http:
+ local currUrl=${COMP_WORDS[i-1]}#//srv-
+ local
partUrl=${COMP_WORDS[i-3]}${COMP_WORDS[i-2]}${COMP_WORDS[i-1]}
+
+ _debug partUrl=${partUrl} cur = ${cur}
+
# see about COMP_WORDBREAKS workaround in prop completion
if [[ $cur == file:* ]]
then
@@ -405,27 +471,50 @@ _svn()
local where=${cur/file:/}
COMPREPLY=( $(compgen -d -S '/' -X '*/.*' -- $where ) )
return
- elif [[ $cur == *:* ]]
+ elif [[ $partUrl == *://*/* ]]
then
+ local IFS=$'\n'
+ # Get the list of remote files (as full paths)
+ local results=$(_svn_remotels ${currUrl} ${prefixUrl}
)
+ COMPREPLY=( $(compgen -W ${results} ))
+ _debug ...completion results are: ${COMPREPLY[@]}
+ # Set output options:
+ # - nospace: DO NOT add a new space even if it's the
only completion
+ # - filenames: remove common leading paths
+ compopt -o nospace -o filenames
+
RE: error on SVN upgrade working copy when repository has been relocated
-Original Message- From: Johannes Lengler [mailto:johannes.leng...@googlemail.com] Sent: vrijdag 27 juli 2012 10:52 To: users@subversion.apache.org Subject: error on SVN upgrade working copy when repository has been relocated The error message has been reported previously, but I did not see that the problem has been resolved: (I had to type by hand as cp did not work) This assertion is caused by a tree conflict containing a url that is not normalized properly according to the 1.7 rules. This issue has been fixed on trunk and the fix will be part of Subversion 1.7.6. (The fix is of course that we normalize this url on import) If possible I would recommend marking the tree conflict as resolved using an old client and then upgrading again. Bert
svnserve authentication using sasl + pam + winbind
Hi is it possible to authenticate users from a Windows active directory to a svnserve daemon? From what I have seen when googeling around was that most of the time the apache module is used when more complex authentication is needed. I would like to avoid the need for an apache on our internal server. Current situation: Ubuntu 12.04 LTS Winbind for domain user authentication on the Linux box svnserve using simple authentication via authz/passwd files Goal: Having only the authz file left with the permissions of the single users to the repos. The authentication should be done using the user database from the windows domain controller. I think SASL + PAM + WINBIND is the way to go. Before I get lost in a lot of documentation on the internet: Has someone done something like this before? Any hints? Thanks Matthias
Issue with merge/integration algorithm?
I feel that the SVN branching and merging/integration algorithm is flawed. However I am not sure if this is a known limitation of SVN. I did 2 tests to compare SVN against Perforce/git. The intention of the test is to see if a change done by a user at some point in time and taken to multiple branches comes back to the main branch duplicated multiple times without indicating a conflict. (Look at the attached tests.txt if the following looks misaligned) Test 1: --- Integrate B1 back to main +---+ | V Main - Branch1 - Branch2 Main Main a a a a a a a b b b b b b b c c c c x c x z z d d d d d z z z z d | z | ^ +-+ Integrate B2 back to main In Perforce/git the result is (without conflict) a b x d z Test 2: --- Integrate B1 back to main ++ | V Main - Branch1 - Branch2 Main Main a a a a a a a a b b b b d d b d c c c c z b c b z z d d c d c z z z z d | z | ^ +-+ Integrate B2 back to main In Perforce/git the result is (without conflict) a d b c z Any thoughts? Test 1: --- Integrate B1 back to main +---+ | V Main - Branch1 - Branch2 Main Main a aa aaaa b bb bbbb c cc cxcx z zd dddd z zzzd | z | ^ +-+ Integrate B2 back to main In Perforce the result is (without conflict) a b x d z Test 2: --- Integrate B1 back to main ++ |V Main - Branch1 - Branch2 Main Main a aa a a aaa b bb b d dbd c cc c z bcb z zd d cdc z z zzd | z | ^ +-+ Integrate B2 back to main In Perforce the result is (without conflict) a d b c z
Re: Issue with merge/integration algorithm?
On Fri, Jul 27, 2012 at 06:11:34AM -0700, Arunmozhi wrote: I feel that the SVN branching and merging/integration algorithm is flawed. However I am not sure if this is a known limitation of SVN. I did 2 tests to compare SVN against Perforce/git. The intention of the test is to see if a change done by a user at some point in time and taken to multiple branches comes back to the main branch duplicated multiple times without indicating a conflict. I'm afraid it's hard to help you based on the information you've given. You're not showing any svn commands you're running. You're not showing the results you got from svn. Without that information it's impossible to tell what you were really doing.
Re: Issue with merge/integration algorithm?
Please look into the attached tests.txt file attached in the initial mail for the input and the result. Each column shows the contents of a file as we do successive changes to the file. I use tortoisesvn 1.7.5 as the user interface and hence I can just list the menu commands corresponding to each step and not the exact SVN commands (I am not used to the command line). The following are the steps I executed for Test 1. (1) Create a file myfile.txt with following contents and add it to the repository (TortoiseSVN - Add, SVN Commit). a b c z (2) Branch the file myfile.txt to a new location (TortoiseSVN - Branch/Tag (From:myfile.txt To:branch1/myfile.txt), SVN update). Now the contents of branch1/myfile.txt is a b c z (3) Edit the branch1/myfile.txt by inserting a line 'd' as follows and then commit the changes (SVN Commit). Now the contents of branch1/myfile.txt is a b c d z (4) Now branch the file branch1/myfile.txt to branch2/myfile.txt (TortoiseSVN - Branch/Tag (From:branch1/myfile.txt To:branch2/myfile.txt), SVN update). Now the contents of branch2/myfile.txt is a b c d z (5) Now edit the file branch2/myfile.txt by changing the 'c' to 'x' and then commit the changes (SVN commit). Now the contents of branch2/myfile.txt is a b x d z (6) Now integrate the branch1/myfile.txt back to myfile.txt (TortoiseSVN - Merge (Reintegrate a branch From:branch1/myfile.txt To working copy:myfile.txt), SVN commit). Now the contents of myfile.txt is a b c d z (7) Now integrate the branch2/myfile.txt back to myfile.txt (TortoiseSVN - Merge (Reintegrate a branch From:branch2/myfile.txt To working copy:myfile.txt), SVN commit). Now the contents of myfile.txt is a b x d d z You can see that the line 'd' appears twice in the integrated file. 'd' is inserted only once in the revision history. The expected output (verified in perforce and git) is a b x d z The second test shown in the attached tests.txt is similar, but shows another clear problem of the line 'd' appearing twice in the integrated file. Final integrated file is shown below. a d b c d z The expected output for the second test as verified in perforce and git is a d b c z Hope now it clarifies the problem. From: Stefan Sperling s...@elego.de To: Arunmozhi arunmozh...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Friday, 27 July 2012 7:06 PM Subject: Re: Issue with merge/integration algorithm? On Fri, Jul 27, 2012 at 06:11:34AM -0700, Arunmozhi wrote: I feel that the SVN branching and merging/integration algorithm is flawed. However I am not sure if this is a known limitation of SVN. I did 2 tests to compare SVN against Perforce/git. The intention of the test is to see if a change done by a user at some point in time and taken to multiple branches comes back to the main branch duplicated multiple times without indicating a conflict. I'm afraid it's hard to help you based on the information you've given. You're not showing any svn commands you're running. You're not showing the results you got from svn. Without that information it's impossible to tell what you were really doing.
Re: Issue with merge/integration algorithm?
I am resending the initial mail as the mail format other than text is not supported. I feel that the SVN branching and merging/integration algorithm is flawed. However I am not sure if this is a known limitation of SVN. I did 2 tests to compare SVN against Perforce/git. The intention of the test is to see if a change done by a user at some point in time and taken to multiple branches comes back to the main branch duplicated multiple times without indicating a conflict. Please look into the attached tests.txt. Each column shows the contents of a file as we do successive changes to the file. Also please refer below the explanatory steps. I use tortoisesvn 1.7.5 as the user interface and hence I can just list the menu commands corresponding to each step and not the exact SVN commands (I am not used to the command line). The following are the steps I executed for Test 1. (1) Create a file myfile.txt with following contents and add it to the repository (TortoiseSVN - Add, SVN Commit). a b c z (2) Branch the file myfile.txt to a new location (TortoiseSVN - Branch/Tag (From:myfile.txt To:branch1/myfile.txt), SVN update). Now the contents of branch1/myfile.txt is a b c z (3) Edit the branch1/myfile.txt by inserting a line 'd' as follows and then commit the changes (SVN Commit). Now the contents of branch1/myfile.txt is a b c d z (4) Now branch the file branch1/myfile.txt to branch2/myfile.txt (TortoiseSVN - Branch/Tag (From:branch1/myfile.txt To:branch2/myfile.txt), SVN update). Now the contents of branch2/myfile.txt is a b c d z (5) Now edit the file branch2/myfile.txt by changing the 'c' to 'x' and then commit the changes (SVN commit). Now the contents of branch2/myfile.txt is a b x d z (6) Now integrate the branch1/myfile.txt back to myfile.txt (TortoiseSVN - Merge (Reintegrate a branch From:branch1/myfile.txt To working copy:myfile.txt), SVN commit). Now the contents of myfile.txt is a b c d z (7) Now integrate the branch2/myfile.txt back to myfile.txt (TortoiseSVN - Merge (Reintegrate a branch From:branch2/myfile.txt To working copy:myfile.txt), SVN commit). Now the contents of myfile.txt is a b x d d z You can see that the line 'd' appears twice in the integrated file. 'd' is inserted only once in the revision history. The expected output (verified in perforce and git) is a b x d z The second test shown in the attached tests.txt is similar, but shows another clear problem of the line 'd' appearing twice in the integrated file. Upto step 4, it is same as for test 1 (5) Edit branch2/myfile.txt and delete 'b' and 'c' and then commit changes a dz (6) Edit branch2/myfile.txt and add 'b' and 'c' below 'd' and then commit changes a d b c z (7) Reintegrate branch1/myfile.txt to myfile.txt a b c d z (8) Reintegrate branch2/myfile.txt to myfile.txt. The final integrated file is shown below. a d b c d z The expected output for the second test as verified in perforce and git is a d b c z Hope now it clarifies the problem. - Original Message - From: Stefan Sperling s...@elego.de To: Arunmozhi arunmozh...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Friday, 27 July 2012 7:06 PM Subject: Re: Issue with merge/integration algorithm? On Fri, Jul 27, 2012 at 06:11:34AM -0700, Arunmozhi wrote: I feel that the SVN branching and merging/integration algorithm is flawed. However I am not sure if this is a known limitation of SVN. I did 2 tests to compare SVN against Perforce/git. The intention of the test is to see if a change done by a user at some point in time and taken to multiple branches comes back to the main branch duplicated multiple times without indicating a conflict. I'm afraid it's hard to help you based on the information you've given. You're not showing any svn commands you're running. You're not showing the results you got from svn. Without that information it's impossible to tell what you were really doing. Test 1: --- Integrate B1 back to main +---+ | V Main - Branch1 - Branch2 Main Main a aa aaaa b bb bbbb c cc cxcx z zd dddd z zzzd | z | ^ +-+ Integrate B2 back to main In Perforce the result is (without conflict) a b x d z Test 2: --- Integrate B1 back to main ++ |V Main - Branch1 - Branch2 Main Main a aa a a aaa b bb b d dbd c cc c z bcb z zd d cdc z z zzd | z | ^
Re: File external that worked fine in 1.6.x not working in 1.7.5
Johan Corveleyn wrote on Thu, Jul 26, 2012 at 23:55:04 +0200: We also talked a bit about the ^/../ in your url's, which was also a bit of a surprise. We didn't know about that feature, but it seems to work fine, and we didn't see a problem with it. Bert added a regression test for it, so it keeps working in future versions :-). Or, at the very least, that we don't break it _unintentionally_. :-)
Re: [PATCH] bash URL completion
http://subversion.apache.org/patches
Please send this to dev@! (and follow the other suggestions too please
-- e.g., submit against trunk@HEAD)
Gerlando Falauto wrote on Fri, Jul 27, 2012 at 11:31:51 +0200:
Hi everyone,
I strongly felt the urge to have some way of bash-completing URLS
from the command line when doing checkouts, listing, cat (for
README/REVNOTES files) and so on...
I looked up the tools/client-side/bash_completion script only to
realize it works for local (file:///) but not remote URLs.
So I came up with the attached patch, which works for me (tested
with bash 4.1.2, svn 1.6.11)
The idea was (apart from adding sub-dir completion with a gross svn
ls command) to (manually) list known repositories within a
~/.svn_repos file, one per line:
http://srv1/proj1
svn://srv2/proj2
The reason behind this is that data cached in
~/.subversion/auth/svn.simple does not contain the full project URL
(only the server name) and I could not find a way to get that
information anywhere else.
I known it would've made more sense to ask for advice *BEFORE*
touching the code, but still... :-)
Thanks in advance for your feedback!
Gerlando
P.S. I'm not subscribed to the list, so please Cc: me, thanks!
diff --git a/svn-completion.bash b/svn-completion.bash
index 12285f4..c2684b3 100644
--- a/svn-completion.bash
+++ b/svn-completion.bash
@@ -35,6 +35,12 @@
shopt -s extglob
+function _debug()
+{
+ # echo $@ /tmp/svn-completion.debug
+ true
+}
+
# Tree helper functions which only use bash, to ease readability.
# look for value associated to key from stdin in K/V hash file format
@@ -112,6 +118,53 @@ function _svn_lls()
done
}
+# _svn_remotels currUrl proto
+# e.g. currUrl = //server/project/dirprefix
+# proto = http:
+# list svn files/dirs (using svn ls) from a given path
+# NOTE: this function outputs full URLs (except the protocol part), like
+# //srv/proj/branches/ //srv/proj/tags/ //srv/proj/trunk/
+function _svn_remotels()
+{
+local currUrl=$1
+local proto=$2
+
+local fullUrl=$2$1
+_debug Trying to complete $opt
+
+# HACK: fullUrl is something like http://srv/proj/ or http://srv/proj/ta
+# so we add an X and get the dirname from there in order to see where we
+# should run svn ls against (that is, http://srv/proj)
+local urlDir=$(dirname ${fullUrl}X)/
+
+# now get the prefix part of the file (e.g. ta for target.def)
+# (this is used for local filtering)
+local filepref=${fullUrl#${urlDir}}
+
+# This output prefix //srv/proj/ will be re-added to the individual ls
entries
+# so to get something like a full path listing (except leading
protocol:)
+local outurlDir=${urlDir#${proto}}
+
+_debug prefix to be matched is $filepref
+
+local files=()
+local f=
+svn ls --non-interactive $urlDir /dev/null 2/dev/null | while IFS=
read -r f
+do
+ _debug -n ... $f:
+ # if the filename matches the provided string, add it to the list
+ if [[ -z $filepref || $f == $filepref* ]]
+ then
+ _debug YES
+echo $outurlDir$f
+else
+ _debug NO
+ fi
+done
+
+return 0
+}
+
# This completion guides the command/option order along the one suggested
# by svn help, although other syntaxes are allowed.
#
@@ -395,9 +448,22 @@ _svn()
fi
# URL completion
- if [[ $cmd == @(co|checkout|ls|list) $stat = 'arg' \
+ if [[ $cmd == @(co|checkout|ls|list|cat) $stat = 'arg' \
$SVN_BASH_COMPL_EXT == *urls* ]]
then
+ # whenever a colon (:) is present, bash will split it into
three different parts:
+ # 1) http
+ # 2) :
+ # 3) //full/path/to
+ # So we need to reconstruct this
+ #FIXME this should be made more robust
+
+ local prefixUrl=${COMP_WORDS[i-3]}${COMP_WORDS[i-2]}#http:
+ local currUrl=${COMP_WORDS[i-1]}#//srv-
+ local
partUrl=${COMP_WORDS[i-3]}${COMP_WORDS[i-2]}${COMP_WORDS[i-1]}
+
+ _debug partUrl=${partUrl} cur = ${cur}
+
# see about COMP_WORDBREAKS workaround in prop completion
if [[ $cur == file:* ]]
then
@@ -405,27 +471,50 @@ _svn()
local where=${cur/file:/}
COMPREPLY=( $(compgen -d -S '/' -X '*/.*' -- $where ) )
return
- elif [[ $cur == *:* ]]
+ elif [[ $partUrl == *://*/* ]]
then
+ local IFS=$'\n'
+ # Get the list of remote files (as full paths)
+ local results=$(_svn_remotels ${currUrl} ${prefixUrl}
)
+ COMPREPLY=( $(compgen -W ${results} ))
+ _debug ...completion results are: ${COMPREPLY[@]}
