Repository name not listed in web
Hello Guys, I have multiple repositories configures using SVNParentPath. The problem I have is that in the web client, in the main page of the repository , the name of the repository is not listed. The value for the SVNReposName is printed, but is common for all repos. How can I have the individual Repo name listed on the root page of the repo's ?? Thanks in advance for your help Thanks and Regards Maxmelbin Neson
Tree conflicts on files added to the branch, then merged into trunk, then merged back into the same branch
Hello, The situation: file is added and committed to a branch, then the same revision is merged into trunk. After that, the range of revisions are merged from trunk back to the same branch which results in a tree conflict on the added file. My understanding of svn:mergeinfo isn't consistent with this behaviour as, to my mind, trunk 'knows' that the file originated from the branch and branch 'knows' that the revision which resulted in the addition of a file had already been merged into trunk. Below is the described scenario reproduced on SVN server v1.6.9 and client v1.6.12 Exists: /trunk svn copy /trunk /branches/branch -m created branch svn co / cd branches/branch echo test newfile svn add newfile A newfile svn commit -m adding newfile Adding branch/newfile Transmitting file data . Committed revision 10. cd ../../trunk svn merge -c 10 /branches/branch --- Merging r10 into '.': Atest svn commit -m merged r10 into trunk Sendingsrc Adding src/test Committed revision 11. svn pg svn:mergeinfo . /branches/branch:10 cd ../branches/branch svn pg svn:mergeinfo . svn log --stop-on-copy r9 | dm3 | 2010-09-07 11:12:55 +0300 (Tue, 07 Sep 2010) | 1 line created branch svn merge -r 9:HEAD /trunk --- Merging r9 through r11 into '.': C test Summary of conflicts: Tree conflicts: 1 sst M . C test local add, incoming add upon merge I would be grateful if you could point me to the explanation of why SVN behaves this way under the given circumstances.
Re: Tree conflicts on files added to the branch, then merged into trunk, then merged back into the same branch
On Tue, Sep 07, 2010 at 12:11:51PM +0300, Vadim wrote: Hello, The situation: file is added and committed to a branch, then the same revision is merged into trunk. After that, the range of revisions are merged from trunk back to the same branch which results in a tree conflict on the added file. My understanding of svn:mergeinfo isn't consistent with this behaviour as, to my mind, trunk 'knows' that the file originated from the branch and branch 'knows' that the revision which resulted in the addition of a file had already been merged into trunk. No. That's not how it works at all. Subversion doesn't know any of that. This is quite a common misconception, so let me try to explain the problem: The way merge-tracking was designed, Subversion treats a path:revision tuple as the unique identifier for changeset to be merged. So Subversion doesn't know whether, say, two changesets /branch:30 and /trunk:42 represent the same semantic change made on different branches (in your case, the semantic change is add file foo.c). To Subversion, these are always different changesets, because they have different identifiers. Only the user knows more. But the real problem is that /trunk:42 might contain more than just the semantic change made in /branch:30. For instance, it might contain additional changes merged from other branches, or changes made during conflict resolution. Even from the design point of view, it seems to be impossible to automatically merge just the part of the /branch:30 changeset as it appears within the /trunk:42 changeset. So the whole /trunk:42 change is always merged, leading to conflicts (both sides say add this file foo.c). Because Subversion cannot currently resolve tree conflicts for the user (it can only detect them), tree conflicts tend to show up most often in these situations. But you can also get text conflicts, for example. There are two ways to deal with this problem: 1) If you know that /trunk:42 is semantically equivalent to /branch:30, you can block the /trunk:42 change on the branch, as described here: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges Then, the branch can sync to the trunk without running into a conflict, because the offending revision will be skipped since it has already been marked as merged. Being able to block revisions like this requires that developers are disciplined about what changes are made in a single commit. 2) The only way to completely avoid this problem is to avoid doing cyclic merges altogether. Make all changes which need to propagate to more than one branch enter your code base at one clearly defined branch. For instance, always make bugfixes in the oldest (or newest) active release branch and merge to other branches from there. Or always make bugfixes in the trunk and merge it to other branches from there. However you do it, if you draw your branching/merging strategy as a diagram showing your branches as horizontal lines and merges as arrows pointing from one of those lines to another line, you must not get cycles. Of course, the current behaviour leaves room for improvement. Once Subversion learns about resolving trivial tree conflicts automatically, the trivial conflicts like both sides say add file foo.c with content X will be automatically resolved and you'll have less chances of running into conflicts requiring manual attention during cyclic merges. However, in general, the problem cannot be solved completely. If you find a way that makes Subversion automatically handle this problem in the general case, you've solved a problem that, so far, nobody has been able to figure out a solution for. AFAIK there is no open source tool which handles this problem nicely. Distributed tools suffer from the same problem, because changeset identifiers are cryptographic hash numbers, and when you cherry-pick changesets between branches, the tool cannot tell whether any two changes with different identifiers are semantically equivalent, so you can get conflicts when you eventually merge the branches. However, they are currently a bit better than Subversion at handling trivial tree conflicts automatically, so it's less of an issue in practice. The only tool I know of which I've been told can do cyclic merging without much help from the user is clear case (though I have my doubts, maybe it just has a good UI for this use case?). If you know of any others, please let me know. Thanks, Stefan
Re: Repository name not listed in web
On Tue, Sep 7, 2010 at 4:35 AM, Neson Maxmelbin (RBEI/EMT5) maxmelbin.ne...@in.bosch.com wrote: Hello Guys, I have multiple repositories configures using SVNParentPath. The problem I have is that in the web client, in the main page of the repository , the name of the repository is not listed. The value for the SVNReposName is printed, but is common for all repos. How can I have the individual Repo name listed on the root page of the repo's ?? Thanks in advance for your help Thanks and Regards Maxmelbin Neson Why not list your Subversion version, your OS, your Apache version, the loation of your multiple repositories, and your 'svn.conf or other Apache file contents used to configure this? In fact, why are you using SVNReposName at all if you have multiple repositories under one parent path? Perhaps you could simply comment that out and see what happens? (I don't have a working HTTP based repository to work with right now: I only allow it for viewing, because of the UNIX and Linux client's willingness to store passwords in clear text on client machines.)
RE: Repository Directory Tree
I *think* that proj1/2/3 are separate projects inside one repository, but none of those distinctions were very clear to me (I DID read the manual, cover to cover). I certainly understand the concept of the equivalence between a directory and project (I think), but, to me, anyway, it's not clear the distinction between a repository and further directory structure. But now my memory returns: I only created ONE repository, so all those are projects under that repository. Thanks for the response! Allen -Original Message- From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] Sent: Monday, September 06, 2010 10:39 AM To: anw-d...@infoisland.net; users@subversion.apache.org Subject: RE: Repository Directory Tree Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 From: Allen Williams [mailto:a...@csunv.com] Sent: 06 September 2010 15:28 To: users@subversion.apache.org Subject: Fwd: Repository Directory Tree I send this email out about once a month or so in what is becoming the vain hope I'll get a response... My subversion repository is in /var/svn. Somehow (and, yes, I'm new; I'm evaluating it), I've wound up with the following directory structure in my subversion repository: /var/svn/ var/svn/proj1 var/svn/proj2 var/svn/proj3. In other words, to do a list of the repositories, I have to do: svn listfile:///var/svn/var/svn to get my projects listed. I've tried to do an svnadmin dump and load with --parent-dir, and that didn't work. This was the command line sequence after I had made a copy of the repository in /var/svn.sav: svnadmin dump /var/svn.sav old_repos rm -r/var/svn/* svnadmin create /var/svn svnadmin load --parent-dir / /var/svn old_repos But, even though I had parent-dir as / (to try to eliminate one of the /var/svn's), I still got /var/svn/var/svn/projects. What is the way to do this? TIA, Allen Is /var/svn one repository and proj1/2/3 directories inside it? or are proj1/2/3 three separate repositories? How did you create you repository or repositories?
RE: Repository Directory Tree
Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- From: Allen Williams [mailto:alad...@csunv.com] Sent: 07 September 2010 12:24 To: users@subversion.apache.org Subject: RE: Repository Directory Tree I *think* that proj1/2/3 are separate projects inside one repository, but none of those distinctions were very clear to me (I DID read the manual, cover to cover). I certainly understand the concept of the equivalence between a directory and project (I think), but, to me, anyway, it's not clear the distinction between a repository and further directory structure. But now my memory returns: I only created ONE repository, so all those are projects under that repository. So /var/svn is a repository, created with svnadmin create /var/svn. The project where imported as var/svn/proj1, var/svn/proj2 and var/svn/proj3. So your projects do live in the var/svn directory in your repository (note there is no / at the beginning so I'm referring to the repository but a directory inside your repository). I would do the following (presuming you're on unix or linux) - check out the whole thing (it might be too big but maybe not) svn checkout file:///var/svn ~/tmp This will create a new directory called tmp in your home directory whit the whole of your repository. Insinde ~/tmp you will have var/svn/proj1, var/svn/proj2 and var/svn/proj3. - move the projects to the root of your repository cd ~/tmp svn move var/svn/proj1 proj1 svn move var/svn/proj2 proj2 svn move var/svn/proj3 proj3 Since you have used svn command the history will be preserved. - commit svn commit -mReorganising the projects Done. Now to see a list of your projects 'svn list file:///var/svn' will be enough. Giulio
Re: Tree conflicts on files added to the branch, then merged into trunk, then merged back into the same branch
Thanks, After you've pointed out the difficulties in recognizing if changesets are indeed equal it seems natural that SVN behaves as it does. The point regarding cyclic branches is valid. We only keep several of those as a convenience to avoid checking out new branches. I'll try to get rid of that practice. The only tool I know of which I've been told can do cyclic merging without much help from the user is clear case (though I have my doubts, maybe it just has a good UI for this use case?). If you know of any others, please let me know. I'm not aware of such tools. So far I had the best merging experience with Git (which handles the described case without any difficulty). On Tue, Sep 7, 2010 at 2:17 PM, Stefan Sperling s...@elego.de wrote: On Tue, Sep 07, 2010 at 12:11:51PM +0300, Vadim wrote: Hello, The situation: file is added and committed to a branch, then the same revision is merged into trunk. After that, the range of revisions are merged from trunk back to the same branch which results in a tree conflict on the added file. My understanding of svn:mergeinfo isn't consistent with this behaviour as, to my mind, trunk 'knows' that the file originated from the branch and branch 'knows' that the revision which resulted in the addition of a file had already been merged into trunk. No. That's not how it works at all. Subversion doesn't know any of that. This is quite a common misconception, so let me try to explain the problem: The way merge-tracking was designed, Subversion treats a path:revision tuple as the unique identifier for changeset to be merged. So Subversion doesn't know whether, say, two changesets /branch:30 and /trunk:42 represent the same semantic change made on different branches (in your case, the semantic change is add file foo.c). To Subversion, these are always different changesets, because they have different identifiers. Only the user knows more. But the real problem is that /trunk:42 might contain more than just the semantic change made in /branch:30. For instance, it might contain additional changes merged from other branches, or changes made during conflict resolution. Even from the design point of view, it seems to be impossible to automatically merge just the part of the /branch:30 changeset as it appears within the /trunk:42 changeset. So the whole /trunk:42 change is always merged, leading to conflicts (both sides say add this file foo.c). Because Subversion cannot currently resolve tree conflicts for the user (it can only detect them), tree conflicts tend to show up most often in these situations. But you can also get text conflicts, for example. There are two ways to deal with this problem: 1) If you know that /trunk:42 is semantically equivalent to /branch:30, you can block the /trunk:42 change on the branch, as described here: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges Then, the branch can sync to the trunk without running into a conflict, because the offending revision will be skipped since it has already been marked as merged. Being able to block revisions like this requires that developers are disciplined about what changes are made in a single commit. 2) The only way to completely avoid this problem is to avoid doing cyclic merges altogether. Make all changes which need to propagate to more than one branch enter your code base at one clearly defined branch. For instance, always make bugfixes in the oldest (or newest) active release branch and merge to other branches from there. Or always make bugfixes in the trunk and merge it to other branches from there. However you do it, if you draw your branching/merging strategy as a diagram showing your branches as horizontal lines and merges as arrows pointing from one of those lines to another line, you must not get cycles. Of course, the current behaviour leaves room for improvement. Once Subversion learns about resolving trivial tree conflicts automatically, the trivial conflicts like both sides say add file foo.c with content X will be automatically resolved and you'll have less chances of running into conflicts requiring manual attention during cyclic merges. However, in general, the problem cannot be solved completely. If you find a way that makes Subversion automatically handle this problem in the general case, you've solved a problem that, so far, nobody has been able to figure out a solution for. AFAIK there is no open source tool which handles this problem nicely. Distributed tools suffer from the same problem, because changeset identifiers are cryptographic hash numbers, and when you cherry-pick changesets between branches, the tool cannot tell whether any two changes with different identifiers are semantically equivalent, so you can get conflicts when you eventually merge the branches. However, they are currently a bit better than
Re: Tree conflicts on files added to the branch, then merged into trunk, then merged back into the same branch
On Tue, Sep 07, 2010 at 04:47:38PM +0300, Vadim wrote: Thanks, After you've pointed out the difficulties in recognizing if changesets are indeed equal it seems natural that SVN behaves as it does. The point regarding cyclic branches is valid. We only keep several of those as a convenience to avoid checking out new branches. I'll try to get rid of that practice. The only tool I know of which I've been told can do cyclic merging without much help from the user is clear case (though I have my doubts, maybe it just has a good UI for this use case?). If you know of any others, please let me know. I'm not aware of such tools. So far I had the best merging experience with Git (which handles the described case without any difficulty). Yes, it does. That's because git has better automatic conflict resolution than Subversion does right now. There's no reason Subversion can't get up to par, but it requires some architectural redesign that's already starting to happen under the covers in the upcoming 1.7 release. But note that the described case (two added files which are equal) is pretty easy to handle. There are many cases in which git will also signal spurious conflicts. I once talked with developers of another project (Mercurial) about this problem, and the result of that discussion was more or less that real semantic merging is still a research topic and not feasible to implement. So users will simply have to live with spurious merge conflicts in some cases. Stefan
RE: Subversion encountered a serious problem - during svn update
I would really really appreciate anyone who has any information they can give me on this? I have not had any reply except for the please don't attach images, which I replied to with full text explanation and apology for my ignorance (sry again!!)... From Tortoise: Subversion encountered a serious problem. Please take the time to report. Subversion reported the following: In file '...\TortoiseSVN-1.6.10\ext\subversion\subversion\libsvn_delta\text_delta.c' line 657: assertion failed (window-sview_len == 0 || (window-sview_offset = ab-sbuf_offset (window- sview_offset + window - sview_len = sbuf_offset + ab-sbuf_len))) From Subclipse: update [working copy] -r HEAD --force Error: org.tigris.subversion.javahl.ClientException: svn: Svndiff has backwards-sliding source views - Repo verified (all 93309 revisions) - Dumped entire repo - Installed latest Subversion (1.6.12) - Created new repo - Loaded new repo from dump Are there any other steps that can be taken or more info I can give that may be helpful? Anyone have a simplified explanation of what is occurring here? Again, checking out HEAD has no problem. It is just updating working copies, and it seems to be picky about when it complains (say 9 - 91000 might whine, but 8 - 91000 might not). Thanks in advance for anything at all! Side ? Is it okay to repost the same question as new if not replied to in some certain timeframe, or am I going at this the right way? Thanks again I @mailinglist noob. Patrick Fletcher Marquis Software Development Business Phone: (850) 877-8864 x132 Business Fax: (850) 877-0359
Re: Subversion encountered a serious problem - during svn update
On Tue, Sep 07, 2010 at 11:19:21AM -0400, Patrick Fletcher wrote:
I would really really appreciate anyone who has any information they can
give me on this? I have not had any reply except for the please don't
attach images, which I replied to with full text explanation and apology
for my ignorance (sry again!!)...
I think your problem sounds like corrupted revisions, but I'm not sure.
Please try to verify each revision of the repository with fsfsverify.py.
http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsverify.py
fsfsverify.py can find corruptions that svnadmin verify doesn't report.
If fsfsverify.py finds a corrupt revision, you can try to fix the revision
file with the -f option. But keep a backup of it before attempting to fix.
I've attached a helper script that you can use to run fsfsverify.py
across multiple repositories.
Also, which version of Subversion are you running on the server?
The pictures attached to your first post contain a screenshot of Subversion
reporting itself as 1.6.3. Are you using that on your server?
If so, upgrade to 1.6.12 ASAP!!! (yes, 3 exclamation marks)
1.6.3 has a known security issue that led to error messages similar to
what you are seeing, if my memory isn't playing tricks on me.
In general, please try to reproduce problems with the lastest version
of the software, always, on both clients and servers. We get quite a
few reports for old problems which have been fixed, but people missed
the fix because they didn't upgrade.
Thanks,
Stefan
#!/bin/sh
# $Id: verify-revisions.sh 280 2010-08-19 15:57:27Z stsp $
# Copyright 2010 Stefan Sperling s...@elego.de, elego Software Solutions GmbH
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
# This script checks all revisions in one or more Subversion FSFS repositories,
# using fsfsverify.py.
if [ -z $1 ]
then
echo Usage: `basename $0` repos1 [repos2 ...]
exit 1
fi
# Select a UNIX tool to produce numerical sequences
if which seq /dev/null 2/dev/null
then
_seq=`which seq`
elif which jot /dev/null 2/dev/null
then
_seq=`which jot`
else
echo No tool for producing numerical sequences found in \$PATH
echo Please install one of these tools: seq, jot
exit 1
fi
# Make sure fsfsverify.py is in $PATH
if ! which fsfsverify.py /dev/null 2/dev/null
then
echo -n fsfsverify.py not found in \$PATH -
echo -n please get fsfsverify.py from
echo
http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsverify.py;
exit 1
fi
let n_repos=0
for repository in $@
do
head_rev=`svnlook youngest \$repository\`
if [ -z $head_rev ]
then
echo -n Cannot determine HEAD revision of repository
echo $repository - skipping
continue
fi
if [ $head_rev == 0 ]
then
echo Repository $repository has zero revisions - skipping
continue
fi
if [ `cat $repository/db/fs-type` != fsfs ]
then
echo -n Repository $repository
echo does not use an FSFS database - skipping
continue
fi
# Check if the repository is sharded
layout_sharded=`grep ^layout sharded $repository/db/format`
if [ -n $layout_sharded ]
then
shards=`echo $layout_sharded | \
sed -e 's/layout sharded \([0-9]*\)/\1/'`
if [ -z $shards ]
then
echo -n Repository $repository seems to be shared,
echo -n but could not determine number of shards -
echo skipping
continue
fi
else
shards=
fi
bad_revs=
for revision in `$_seq $head_rev`
do
if [ -n $shards ]
then
shard_dir=`expr $revision / $shards`
else
shard_dir=
fi
if [ -f $repository/db/revs/${shard_dir}.pack ]
then
echo -n Repository $repository has packing enabled
echo but fsfsverify.py does not support packed
RE: Subversion encountered a serious problem - during svn update
Thanks for super fast reply Stefan (yes, 4 exclamations) I've attached a helper script that you can use to run fsfsverify.py across multiple repositories. I'm running windows here and I can't get this to work in Cygwin (please excuse me if I'm just being ignorant - Unix/Python deficient) * patri...@desk28 ~/Desktop $ ./verify-revisions.sh G:/Subversion/Repositories/eomis ./verify-revisions.sh: line 3: $'\r': command not found ./verify-revisions.sh: line 17: $'\r': command not found ./verify-revisions.sh: line 20: $'\r': command not found ./verify-revisions.sh: line 31: syntax error near unexpected token `elif' '/verify-revisions.sh: line 31: `elif which jot /dev/null 2/dev/null * Googling around, I cannot find flag explanations for fsfsverify.py, and only really see examples about using -f flag to fix a single revision identified by the separate svnadmin verify (which as you know didn't report anything for my repo). Also, which version of Subversion are you running on the server? Originally we had 1.6.3 as you saw, but in the time since the last question (not the one you replied to) I installed 1.6.12 on both client and server. Did a full dump (93309 revs), and loaded into a newly created repo. I believe that I read this was the recommended way of upgrading and figured it couldn't hurt anything in my situation so I did it even though it says no more format updates until a 2 release. In general, please try to reproduce problems with the latest version of the software, always, on both clients and servers. We get quite a few reports for old problems which have been fixed, but people missed the fix because they didn't upgrade. Duly noted. I noticed my idiocy shortly after one of my other posts. Thanks again Patrick Fletcher Marquis Software Development Business Phone: (850) 877-8864 x132 Business Fax: (850) 877-0359 -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Tuesday, September 07, 2010 11:50 AM To: Patrick Fletcher Cc: users@subversion.apache.org; 'Daniel Shahaf'; 'Andy Levy' Subject: Re: Subversion encountered a serious problem - during svn update On Tue, Sep 07, 2010 at 11:19:21AM -0400, Patrick Fletcher wrote: I would really really appreciate anyone who has any information they can give me on this? I have not had any reply except for the please don't attach images, which I replied to with full text explanation and apology for my ignorance (sry again!!)... I think your problem sounds like corrupted revisions, but I'm not sure. Please try to verify each revision of the repository with fsfsverify.py. http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsfsver ify.py fsfsverify.py can find corruptions that svnadmin verify doesn't report. If fsfsverify.py finds a corrupt revision, you can try to fix the revision file with the -f option. But keep a backup of it before attempting to fix. I've attached a helper script that you can use to run fsfsverify.py across multiple repositories. Also, which version of Subversion are you running on the server? The pictures attached to your first post contain a screenshot of Subversion reporting itself as 1.6.3. Are you using that on your server? If so, upgrade to 1.6.12 ASAP!!! (yes, 3 exclamation marks) 1.6.3 has a known security issue that led to error messages similar to what you are seeing, if my memory isn't playing tricks on me. In general, please try to reproduce problems with the lastest version of the software, always, on both clients and servers. We get quite a few reports for old problems which have been fixed, but people missed the fix because they didn't upgrade. Thanks, Stefan
RE: Subversion encountered a serious problem - during svn update
Definitely not. Cygwin was in reference to the helper script Stefan sent me (verify-revisions.sh). Am I missing something? Can that be run on a windows machine without something like cygwin? Patrick Fletcher Marquis Software Development Business Phone: (850) 877-8864 x132 Business Fax: (850) 877-0359 -Original Message- From: Andy Levy [mailto:andy.l...@gmail.com] Sent: Tuesday, September 07, 2010 1:09 PM To: Patrick Fletcher Cc: Stefan Sperling; users@subversion.apache.org Subject: Re: Subversion encountered a serious problem - during svn update On Tue, Sep 7, 2010 at 12:59, Patrick Fletcher patrick.fletc...@marquisware.com wrote: Thanks for super fast reply Stefan (yes, 4 exclamations) I've attached a helper script that you can use to run fsfsverify.py across multiple repositories. I'm running windows here and I can't get this to work in Cygwin (please excuse me if I'm just being ignorant - Unix/Python deficient) * patri...@desk28 ~/Desktop $ ./verify-revisions.sh G:/Subversion/Repositories/eomis ./verify-revisions.sh: line 3: $'\r': command not found ./verify-revisions.sh: line 17: $'\r': command not found ./verify-revisions.sh: line 20: $'\r': command not found ./verify-revisions.sh: line 31: syntax error near unexpected token `elif' '/verify-revisions.sh: line 31: `elif which jot /dev/null 2/dev/null * Googling around, I cannot find flag explanations for fsfsverify.py, and only really see examples about using -f flag to fix a single revision identified by the separate svnadmin verify (which as you know didn't report anything for my repo). Does fsfsverify.py require Cygwin? You shouldn't need it, and in fact the Cygwin Subversion client has been known to cause issues since you're telling it to pretend it's on *NIX when it's really on Windows. Both Subversion and Python run perfectly fine as Win32 native programs. You aren't running svnserve or Apache via Cygwin on your server, are you?
Re: Subversion encountered a serious problem - during svn update
On Tue, Sep 07, 2010 at 03:09:15PM -0400, Patrick Fletcher wrote: Ahh... Thanks a bunch. The Python file indeed had similar errors. Now when I run I get: patri...@desk28 /cygdrive/g/Subversion $ ./verify-revisions.sh Repositories/eomis_1_6_12 /usr/bin/seq: invalid floating point argument: 93909 Try `/usr/bin/seq --help' for more information. 93909 is HEAD revision. Any ideas? I'm not a windows expert so the script may fail on cygwin. I've tested it on Linux and BSD. But if you already know which revisions are problematic, you don't need my script. Just run fsfsverify.py on the problematic revisions directly. For instance: fsfsverify.py /path/to/repos/db/revs/0/42 Stefan
RE: Subversion encountered a serious problem - during svn update
I see. I have no idea which revisions are problematic as a whole, I have only run into specific cases, of which the only way I could get around and continue working was to dump working copy and checkout HEAD again. Only reason cygwin came into picture was to run the .sh file. I have already run and the normal svnadmin verify which says everything is fine... Still trying to pinpoint where and what the actual problem is. The info in the first email was just to try to help. I have no idea what the actual problem could be. I believe you said this was a more thorough examination (may turn up things svnadmin verify will not). Can I command line the fsfsverify.py to check every revision? If not, can I just write something to do it for me iteratively... Obviously don't want to fix (-f) anything yet as I don't know where the problem lies, but I can find no explanation of the other flags available and I am python nub. Thanks for bearing with me! Patrick Fletcher Marquis Software Development Business Phone: (850) 877-8864 x132 Business Fax: (850) 877-0359 -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Tuesday, September 07, 2010 4:30 PM To: Patrick Fletcher Cc: Tony Sweeney; users@subversion.apache.org Subject: Re: Subversion encountered a serious problem - during svn update On Tue, Sep 07, 2010 at 03:09:15PM -0400, Patrick Fletcher wrote: Ahh... Thanks a bunch. The Python file indeed had similar errors. Now when I run I get: patri...@desk28 /cygdrive/g/Subversion $ ./verify-revisions.sh Repositories/eomis_1_6_12 /usr/bin/seq: invalid floating point argument: 93909 Try `/usr/bin/seq --help' for more information. 93909 is HEAD revision. Any ideas? I'm not a windows expert so the script may fail on cygwin. I've tested it on Linux and BSD. But if you already know which revisions are problematic, you don't need my script. Just run fsfsverify.py on the problematic revisions directly. For instance: fsfsverify.py /path/to/repos/db/revs/0/42 Stefan
