Re: svnlook issue
On Oct 28, 2011, at 19:37, Bruce Vining wrote: > I have been using Subversion flawlessly (and happily) now for the past 6 > months but performed the latest update via the Web Interface (Collabnet > Subversion Edge) and now I have hell to pay. > > For the past 6 months I have been successfully using the post-commit bash > script in the /hooks subfolder located under my SVN repositories to call a > perl script commit-email.pl. I am not sure if you are familiar with this > specific perl script, but it will email source changes to designated users > upon change commit events in SVN. Post-update, I immediately began getting > errors on the parameter list submitted to the svnlook command in said perl > script and discovered that with the new update “rev” has been replaced with > “–r” as a valid parameter identifier for this command. I had replaced all > occurrences and this action corrected respective problem being reported. > > Now, to the next issue, when using the following command: > > ./svnlook info ats-mysqlbu -r 4 > > I am getting an error as follows: > > svnlook: E02: Can't open file 'ats-mysqlbu/format': No such file or > directory > > Where ats-mysqlbu is a repository that I created a few months back. In fact > I am seeing an error which shows the “/format” string being appended to my > repository name in every case where I use the svnlook command. As I said > before this command has worked flawlessly up to today, when I performed the > update. All I can say is... * Yes, you use "-r X" to look at revision X. I don't know where "rev" came from but it must be a very old syntax that predates my involvement with the project (which began in 2004). * Yes, svnlook looks for a format file inside your repository. My repository directories all contain that file. Don't yours? * The commit-email.pl script was deprecated years ago; the replacement is mailer.py: http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/mailer/
Working SRPM and .spec files for subversion-1.7.1
For various reasons, I've been working on RPM packaging of 1.7.0 and now 1.7.1. I'd like to get the old "packages/rpm" structure replaced with it, and I'm trying to get it into RPMforge. It's built from the Fedora packaging of subversion-1.6.17, and most of the patches are no longer needed (because they're for the "contrib" utilities". What's the best way to get that submitted? The .spec file is aobut 36 K, the single patch file (for an old Debian reported bug) is about 12 K.
Re: SVN repo cross-platform compatibility
On Wed, Oct 26, 2011 at 7:23 AM, Neil Bird wrote: > > Whilst suffering a subversion server outage, it's made me wonder: we > currently produce nightly backups of our repos via 'hotcopy' from the > server's local drive to a network store. > > If the server were to die, would I be able to take those copies and place > them under a server on a new box *with a different OS*? Or would I have to > create a temporary server with the original OS, copy them to that, and > svndump them and import them elsewhere? > > In this case, it's a Solaris server, dunno what processor [I'll check when > it's back up!], and I'd consider moving it to an x86 Linux server. Never do this by direct filesystem replication. "hotcopy" is somewhat better. Issues with transfer via hotcopy include the fact that hotcopy *does not* replicate file permissions and file ownership, it simply copies them as whoever runs the "svnadmin hotcopy" command. That can cause *enormous* problems in various configurations. And between operating systems, the "hook" or "conf" tools that are incompatible between the system's scripting languages. Worse, if your new OS does not have an equal or greater Subversion major release, the hotcopy will likely be incompatibile with the new OS. I spent one *hell* of a time last year, when someone had been running a handbuilt Subversion binary with a manually built and awkwardly configured service, and I was prevented by "policy" from updating the Subversion on RHEL 5.x, which was Subversion 1.4.x, to the publicly available Subversion 1.6.x from RPMforge. So I was compelled for political reasons, not techinical reasons, to continue to support the older and more fragile environments, and not permitted to migrate them for quite a long time. That said, you also face a very dangerous "split brain" issue if you simply set up the replicated, up to 24 hours out of date copy elsewhere and set up the same uuid, so users who've already checked out or checked in changes since the last snapshot will have a local working copy that is dangerously out of sync with the replica. Two diferent working copies can wind up with different ideas of whatever revisions occurred, and may wind up out of sync between the two repositories. All that said, Solaris=>Linux is fortunately a fairly easy migration. Similar releases of Subversion are available, unless you have a seriously out of date system that policy forbids you from updating. The trick is to keep the *non* db files, the hooks and conf files, mirrored separately and regularly, and keep a Linux read-only repository mirrored with "svnsync", Properly managed, the "svnsync" can even be triggered to occur after every successful commit, and always keep you within one revision of the master repository. If you have to do the replica, *use a new uuid* and inform your users that they have to deal with a new repository.
Re: tortoise 1.7 - error on repository manipulation
Erwane Breton wrote on Fri, Oct 28, 2011 at 12:31:52 +0200: > The install of my virtualbox, for Daniel Shahaf, maybe solved the > problem, in local. > If it's work with minimal configuration, something goes wrong in my > apache config. > If you find what the problem was, please post back to the thread describing it, for completeness of the archives. Thanks. > > Thanks everyone for helping me :) > Welcome.
Re: First Hands-on Subversion—Where/How?
On Oct 28, 2011, at 5:52 PM, Pietro Moras wrote: > > more specific questions > > My pleasure, dear Geoff, >Here you have some very Specific Questions. > > SQ1] How to get what I presume is a nice Subversion prompt: > > $ > > on one of my standard Windows machines, so to test the wonderful Subversion > commands so eloquently described by the mentioned self-declared Official > Guide and Reference Manual, so practically useless at the very beginning of a > learning process; that is, exactly when you need most practical and effective > information and support? I think the idea of the book is that it's a guide on how to *use* Subversion, not a guide on how to *get* it. As a parallel, books on how to use MS Word don't tell you on page 1 that the first step is to visit your favorite software retailer and purchase a copy of Word--they assume that you already have Word installed. > SQ2] Why should I go scrabbling and begging via Google for practical, > operative info, I'd reasonably expected to find right away at page 1 on the > mentioned book, or at the page 1 on the Subversion web site? It is one the figurative page 1 of the Subversion web site. The navigation menu on the left side of http://subversion.apache.org/ has a "Getting Subversion" section. Click the Binary Packages link, then the Windows link, then choose any of the packages that are listed. > > SQ3] Am I the first Subversion potential user starting from scratch? >Everybody else knowing how to set-up a Subversion environment even before > beginning to use it? The documentation has instructions on how to set up a Subversion environment.
Re: First Hands-on Subversion—Where/How?
Dear Pietro,
I think you should start your learning Subversion from learning what a
"command line" is. Subversion manual is no substitute for knowing the OS.
Or alternatively, have someone install a repostory for you and go with a GUI
client, such as TortoiseSVN.
Regards,
Alexey.
On Friday, October 28, 2011 03:52:31 pm Pietro Moras wrote:
> more specific questions
>
>
>
> My pleasure, dear
> Geoff, Here you have some
> very Specific Questions.
>
> SQ1] How to get what I
> presume is a nice Subversion prompt:
>
> $
>on one of my
> standard Windows machines, so to test the wonderful Subversion
> commands so eloquently described by the mentioned self-declared
> Official Guide and Reference Manual, so practically useless at the
> very beginning of a learning process; that is, exactly when you need
> most practical and effective information and support?
>
>
> SQ2] Why should I go
> scrabbling and begging via Google for practical, operative info, I'd
> reasonably expected to find right away at page 1 on the mentioned
> book, or at the page 1 on the Subversion web site?
>
>
> SQ3] Am I the first
> Subversion potential user starting from scratch?
>Everybody else
> knowing how to set-up a Subversion environment even before beginning
> to use it?
>
> Of course thank you for
> pointing me to the right direction. Of course.
>
> All the best. Yours, - P.M.
>
> Date: Fri, 28 Oct 2011 11:20:54 -0700
> Subject: Re: First Hands-on Subversion—Where/How?
> From: ghoff...@cardinalpath.com
> To: studio...@hotmail.com
> CC: users@subversion.apache.org
>
>
>
> On Fri, Oct 28, 2011 at 11:00 AM, Pietro Moras
> wrote:
>
>
>
>
>
>
>
>
>
>
>
> Dear Subversion
> cognoscenti,
>
> Seriously
> intentioned to explore what Subversion is all about, armed with good
> will and a good reference book (“Version Control with Subversion”,
> by Ben Collins-Sussman, Brian W. Fitzpatrick, C.
> Michael Pilato),
> I got immediately lost & stuck at the very first command:
>
> $
> svn help
>
>
>
> ?] That said, where/how on earth
> could I get such Subversion grass-roots commands working?Is there any
> practical way, any practical tool, any practical good soul/good
> organisation where to find a test client-server setup where to
> (seriously) “play” with Subversion VCS? I'd be happy to begin
> even with a tiny a client-server set-up onto a machine of mine, would
> such a tool available; even no idea whether such a naïve idea of
> mine is feasible or not.
>
> Gratefully yours,
>
> -
> P.M.
>
>
> Ref.:
> dr. Pietro Moras
> Email
> studio...@hotmail.com
>
>
>
> Greetings Pietro,
> Start here http://svnbook.red-bean.com/
> Then I would recommend a Google search like install subversion
> {platform_or_distro_you_use} -- for example here's a good quick overview
> at Ubuntu https://help.ubuntu.com/community/Subversion
>
> Remember, `Subversion` is both a client software and a server software, so
> it doesn't do you much good to learn `svn ___` (client) unless you have
> already used svnadmin to create a repository... (server). You can do this
> all locally, or on a VM (I would recommend go this route, eg virtualbox,
> if you're on Windows).
>
> Post back here with more specific questions as you go.
Re: First Hands-on Subversion—Where/How?
On Fri, Oct 28, 2011 at 3:52 PM, Pietro Moras wrote: > > more specific questions > > My pleasure, dear Geoff, >Here you have some very Specific Questions. > > SQ1] How to get what I presume is a nice Subversion prompt: > > $ > > There is no prompt, other than terminal. Read the redbook please... or #> svn --help CollabNet ( http://www.collab.net/downloads/subversion/ ) makes the most well known Windows ports of the software, with regular Windows installers for the software. Look for Subversion Edge: A certified software stack containing the latest versions of Subversion, Apache, and ViewVC: That's the fastest way to get started on Windows, IMO. Used to be free, don't know if it is anymore. OR -- The other thing you might want to do is sign up for a free trial at SpringLoops.com or Beanstalkapp.com -- there you can have the "Subversion Server" part all figured out for you, so you can play with the client only. Configuring the server is somewhat non-trivial for a beginner especially. on one of my standard Windows machines, so to test the wonderful Subversion > commands so eloquently described by the mentioned self-declared Official > Guide and Reference Manual, so practically useless at the very beginning of > a learning process; that is, exactly when you need most practical and > effective information and support? > > SQ2] Why should I go scrabbling and begging via Google for practical, > operative info, I'd reasonably expected to find right away at page 1 on the > mentioned book, or at the page 1 on the Subversion web site? > > Because lots of people have posted lots of info and tutorials on the topic. > SQ3] Am I the first Subversion potential user starting from scratch? >Everybody else knowing how to set-up a Subversion environment even > before beginning to use it? > Nope, they all went to Google and the Redbean book. > Of course thank you for pointing me to the right direction. Of course. > All the best. Yours, > - P.M. > > You're welcome -
RE: First Hands-on Subversion—Where/How?
>
more specific questions
My pleasure, dear
Geoff, Here you have some
very Specific Questions.
SQ1] How to get what I
presume is a nice Subversion prompt:
$
on one of my
standard Windows machines, so to test the wonderful Subversion
commands so eloquently described by the mentioned self-declared
Official Guide and Reference Manual, so practically useless at the
very beginning of a learning process; that is, exactly when you need
most practical and effective information and support?
SQ2] Why should I go
scrabbling and begging via Google for practical, operative info, I'd
reasonably expected to find right away at page 1 on the mentioned
book, or at the page 1 on the Subversion web site?
SQ3] Am I the first
Subversion potential user starting from scratch?
Everybody else
knowing how to set-up a Subversion environment even before beginning
to use it?
Of course thank you for
pointing me to the right direction. Of course.
All the best. Yours, - P.M.
Date: Fri, 28 Oct 2011 11:20:54 -0700
Subject: Re: First Hands-on Subversion—Where/How?
From: ghoff...@cardinalpath.com
To: studio...@hotmail.com
CC: users@subversion.apache.org
On Fri, Oct 28, 2011 at 11:00 AM, Pietro Moras wrote:
Dear Subversion
cognoscenti,
Seriously
intentioned to explore what Subversion is all about, armed with good
will and a good reference book (“Version Control with Subversion”,
by Ben Collins-Sussman, Brian W. Fitzpatrick, C.
Michael Pilato),
I got immediately lost & stuck at the very first command:
$
svn help
?] That said, where/how on earth
could I get such Subversion grass-roots commands working?Is there any
practical way, any practical tool, any practical good soul/good
organisation where to find a test client-server setup where to
(seriously) “play” with Subversion VCS? I'd be happy to begin
even with a tiny a client-server set-up onto a machine of mine, would
such a tool available; even no idea whether such a naïve idea of
mine is feasible or not.
Gratefully yours,
-
P.M.
Ref.:
dr. Pietro Moras
Email
studio...@hotmail.com
Greetings Pietro,
Start here http://svnbook.red-bean.com/
Then I would recommend a Google search like install subversion
{platform_or_distro_you_use} -- for example here's a good quick overview at
Ubuntu https://help.ubuntu.com/community/Subversion
Remember, `Subversion` is both a client software and a server software, so it
doesn't do you much good to learn `svn ___` (client) unless you have already
used svnadmin to create a repository... (server). You can do this all locally,
or on a VM (I would recommend go this route, eg virtualbox, if you're on
Windows).
Post back here with more specific questions as you go.
Re: First Hands-on Subversion—Where/How?
On Fri, Oct 28, 2011 at 11:00 AM, Pietro Moras wrote:
> Dear Subversion cognoscenti,
>
> Seriously intentioned to explore what Subversion is all about, armed
> with good will and a good reference book (“Version Control with
> Subversion”, by Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael
> Pilato), I got immediately lost & stuck at the very first command:
>
> $ svn help
>
>
> ?] That said, where/how on earth could I get such Subversion grass-roots
> commands working?
>
>Is there any practical way, any practical tool, any practical good
> soul/good organisation where to find a test client-server setup where to
> (seriously) “play” with Subversion VCS? I'd be happy to begin even with a
> tiny a client-server set-up onto a machine of mine, would such a tool
> available; even no idea whether such a naïve idea of mine is feasible or
> not.
>
> Gratefully yours,
>
> - P.M.
>
> Ref.:
> dr. Pietro Moras
> Email studio...@hotmail.com
>
Greetings Pietro,
Start here http://svnbook.red-bean.com/
Then I would recommend a Google search like *install subversion
{platform_or_distro_you_use}* -- for example here's a good quick overview
at Ubuntu https://help.ubuntu.com/community/Subversion
Remember, `Subversion` is both a client software and a server software, so
it doesn't do you much good to learn `svn ___` (client) unless you have
already used svnadmin to create a repository... (server). You can do this
all locally, or on a VM (I would recommend go this route, eg virtualbox, if
you're on Windows).
Post back here with more specific questions as you go.
First Hands-on Subversion—Where/How?
Dear Subversion cognoscenti, Seriously intentioned to explore what Subversion is all about, armed with good will and a good reference book (“Version Control with Subversion”, by Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato), I got immediately lost & stuck at the very first command: $ svn help ?] That said, where/how on earth could I get such Subversion grass-roots commands working?Is there any practical way, any practical tool, any practical good soul/good organisation where to find a test client-server setup where to (seriously) “play” with Subversion VCS? I'd be happy to begin even with a tiny a client-server set-up onto a machine of mine, would such a tool available; even no idea whether such a naïve idea of mine is feasible or not. Gratefully yours, - P.M. Ref.: dr. Pietro Moras Email studio...@hotmail.com
Re: tortoise 1.7 - error on repository manipulation
On 10/28/2011 2:41 AM, Stefan Sperling wrote: On Thu, Oct 27, 2011 at 04:19:54PM +0200, Erwane Breton wrote: The error is always the same Commit Commit failed (details follow): '/svn/site/*!svn/me*' path not found My repository is https://xyz.coda-cola.net/svn/site/trunk I've tried svnadmin upgrade, exactly the same. apache debug error logs (without openSSL informations) A shot in the dark: Is it possible that you accidentally loaded mod_dav_svn from Subversion 1.7 and mod_authz_svn from Subversion 1.6? Because this looks as if the client thinks the server supports HTTPv2, but the server does not actually support it. Which is weird, because mod_dav_svn apparently negotiated HTTPv2 with the client, so it should work. The only possible explanation I can come up with is that parts of your server are running 1.6 code, and other parts are running 1.7 code. I seem to recall there was a bug where the 1.7 mod_dav_svn was intercepting all POST messages regardless of destination. So I guess this could happen if you have both 1.6 and 1.7 exposed through the same instance of Apache, and then try to connect to the 1.6 server. Looks like that bug was fixed on trunk in r1187695, if that turns out to be relevant. -Mike
ANNOUNCE: svnfiltereddump 1.0 Beta available
Hello, a new open source tool for reorganizing Subversion repositories was released. It is optimized to extract parts of a large repository to form a new smaller one. It is similar in purpose to svndumpfilter (standard SVN tool) and Simon Tatham's svndumpfilter2 (*). However it is has less limitations. In addition it has the ability to drop old revisions before a given revision number. For more details see: https://github.com/TNG/svnfiltereddump/wiki/Formated-Man-Page You may get svnfiltereddump via pip (a Python package installer): sudo pip install svnfiltereddump For those lacking Internet access or root permissions there is also a manual installation procedure - again see the man page for details. The software is considered beta at the moment - mostly because we lack tests on large source repositories. If you can report practical real-life experience on large repositories (e.g. >25GB, >10 revisions) that would be highly welcome - even if it's just "worked". Regards Harald Wilhelmi *) Simon Tatham's Tool: http://svn.tartarus.org/sgt/svn-tools/svndumpfilter2 -- Harald Wilhelmi Partner TNG Technology Consulting GmbH harald.wilhe...@tngtech.com TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring Geschäftsführer: Henrik Klagges, Gerhard Müller, Christoph Stock Amtsgericht München, HRB 135082
Re: Subversion Exception
On Fri, Oct 28, 2011 at 01:20:52PM +0100, Stephen Flowers wrote: > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing list > with as much information as possible about what > you were trying to do. > But please first search the mailing list archives for the error message > to avoid reporting the same problem repeatedly. > You can find the mailing list archives at > http://subversion.apache.org/mailing-lists.html > > 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.1\ext\subversion\subversion\libsvn_wc\workqueue.c' > line 672: assertion failed (checksum != NULL) > --- > OK > --- Please check out a new working copy. This working copy was probably upgraded with 1.7.0, and there is a known upgrade bug in that version which can trigger this error. The error triggers with 1.7.1 also if the working copy was upgraded with 1.7.0. But it should not happen with a new checkout. If you keep seeing this problem with a new checkout, please let us know. Thanks.
update --depth=empty ignored since 1.7
Dear list, I'm experiencing some weird behaviour of SVN 1.7. The following sequence of commands fails to respect --depth=empty: svn co --depth=empty http://foundry.supelec.fr/svn/metapost svn up --depth=empty metapost/tags (you can use 'anonymous' as a username if it asks) The first command runs fine, but the second one starts fetching all tags. The workaround is to use svn up --set-depth empty metapost/tags before fetching anything with "svn up", but --depts=empty seems to be respected in 1.6.16 and also makes a lot more sense the way it worked earlier. Is this a bug or my misunderstanding of how the above commands are supposed to work? I noticed that some depth=empty-related issues are mentioned in changelog for 1.7.1, but subversion 1.7.1 as shipped with MacPorts on Mac OS X 10.7 doesn't seem to solve the problem for me. Thank you very much, Mojca
Subversion Exception
--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html 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.1\ext\subversion\subversion\libsvn_wc\workqueue.c' line 672: assertion failed (checksum != NULL) --- OK ---
Re: merge disagrees with diff
On Fri, Oct 28, 2011 at 2:00 PM, Andreas Krey wrote:
> That only looks like that because of the way merging is described in the
> book.
Aaah! RTFM, is it?
> In essence, svn sees only two different (and conflicting) changes to
> a block of lines, and leaves it to you to deal with that. (Likewise
> do git and CVS.)
>
> This looks pretty much like your situation.
My god man! you're right!
I've managed to write a very minimal test case which demonstrates the problem:
#!/usr/bin/perl
use strict;
use warnings;
use FindBin qw($Bin);
system("svnadmin create repo") and die;
system("svn", 'co', "file://$Bin/repo", "checkout") and die;
open A, ">checkout/a" or die "Failed to create a: $!";
for my $i (1..10) {
print A "$i\n";
}
close A;
open B, ">checkout/b" or die "Failed to create b: $!";
for my $i (1..10) {
print B "$i\n";
print B "$i and a half\n" if $i == 5;
}
close B;
system("svn", "add", "checkout/a", "checkout/b") and die;
system("svn", "ci", "checkout", "-m", "Added some files to test on") and die;
open B, ">checkout/b" or die "Failed to create b: $!";
for my $i (1..10) {
print B "$i\n";
print B "$i and a quarter\n" if $i == 5;
print B "$i and a half\n" if $i == 5;
}
close B;
system("svn", "ci", "checkout", "-m", "Added an extra line") and die;
system("svn", "diff", "-c", '2', "file://$Bin/repo") and die;
system("svn", "merge", '--non-interactive', "-c", '2',
"file://$Bin/repo/b", "checkout/a") and die;
The change to b that I merge is:
Index: b
===
--- b (revision 1)
+++ b (revision 2)
@@ -3,6 +3,7 @@
3
4
5
+5 and a quarter
5 and a half
6
7
The conflict in a ends up being:
1
2
3
4
5
<<< .working
===
5 and a quarter
5 and a half
>>> .merge-right.r2
6
7
8
9
10
I'm comforted that this only happens when there is a conflict, but
it's still terribly confusing for people and I wonder if trying to
apply the diff (as reported by svn diff) would lead to a less
confusing conflict as you would only have to deal with the actual
change you wanted to merge rather than the entire
Thank you all for your time.
--
Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: merge disagrees with diff
On Fri, Oct 28, 2011 at 2:19 PM, Stefan Sperling wrote: > Does this explanation make sense? Yes, very much, thank you for taking your time to look into this for me, I'm sorry to have inconvenienced you, but hopefully someone with the same problem will find the thread and be enlightened. -- Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: merge disagrees with diff
On Fri, Oct 28, 2011 at 01:02:05PM +0200, Flemming Frandsen wrote:
> On Fri, Oct 28, 2011 at 12:58 PM, Andreas Krey wrote:
> > You didn't get a clean merge; you got a conflict. When you get a conflict,
> > it is your job to look at what you merged and at the proposed result,
> > and resolve it yourself.
>
> Yes, I have seen conflicts before, that's not what the problem is, I
> know how to handle conflicts.
>
> > (Can't tell without the three versions that have been requested.)
>
> Those versions were sent to the developer who requested them, I'd
> rather not have them on the public mailing list.
>
> The problem is that there are many more changes in the conflicted
> block than the diff suggested, iow: svn merge tried to add more lines
> than svn diff said it would.
I've taken a look at the files.
My brief analysis suggests that you are simply running into a case
where the diff3 algorithm doesn't work very well.
If you manually diff the files, you'll see that the extra block
of text which ended up in the merge target is the exact difference
between the merge-target and the merge-left version of the file.
I.e. try this (using the names of the files you sent me):
diff -u stepws-5.2.1-610503.xsd stepws-5.2.2-648290.xsd
diff -u stepws-5.2.2-648290.xsd stepws-5.2.2-648291.xsd
The first diff shows the "spurious" block being added ("bad block").
The second diff shows the block you want being added ("good block").
So why does Subversion end up showing both blocks?
The answer is that it has no way of matching the good block to
any postition in the merge-target, because it doesn't match anywhere.
Internally, the 3-way diff produced from the input files looks like this
(the decimal numbers below are line numbers, so you can easily verify
where the diff3 algorithm is pin-pointing region boundaries in the files):
(gdb) p *diff
$12 = {next = 0x20a346658, type = svn_diff__type_conflict,
original_start = 368, original_length = 36,
modified_start = 368, modified_length = 0,
latest_start = 368, latest_length = 67,
resolved_diff = 0x20a346610}
'original' is stepws-5.2.2-648290.xsd ("merge-left")
'modified' is stepws-5.2.1-610503) ("merge-target")
'latest' is stepws-5.2.2-648291.xsd("merge-right")
As you can see, the diff3 algorithm found no section where the diff
between 'original' and 'latest' could be applied to 'modified'
(modified_length is zero).
This is because 'original' is assumed to be the last common version.
diff3 compares 'original' to 'modified' and 'original' to 'latest':
diff 'original'->'modified'
diff 'original'->'latest'
(see www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf)
Because you are cherry-picking to an old branch, th historical correspondance
between 'original' and 'modified' conflicts with the assumptions diff3 is
makeing. In fact, 'modified' equals 'original' if you remove the "bad block"
from 'original'. Your 'original' is really a newer version of the file
than 'modified' is.
So there is conflict, and what Subversion does in this case produces the
result you see. What it shows you is a diff2 between the 'modified' version
and the 'latest' version. This is deliberate, see this comment in
subversion/libsvn_diff/diff3.c:
/* ### If we have a conflict we can try to find the
* ### common parts in it by getting an lcs between
* ### modified (start to start + length) and
* ### latest (start to start + length).
* ### We use this lcs to create a simple diff. Only
* ### where there is a diff between the two, we have
* ### a conflict.
Obviously, this diff will not show what you tried to merge.
You were expecting to see the diff between 'original' and 'latest',
but Subversion shows the diff between 'modified' and 'latest'.
I would say this is working as designed.
You might argue that what Subversion is displaying in your case is
confusing, but off-hand I wouldn't know if there is a better way to
deal with this situation.
Even standard UNIX diff tools like diff3(1) and merge(1) (uses diff3)
produce the same result.
E.g. try this command, which outputs the same "bad block" as
Subversion does:
diff3 stepws-5.2.2-648290.xsd stepws-5.2.1-610503.xsd stepws-5.2.2-648291.xsd
With merge(1) I get the same result as Subversion produces, too:
merge -p -E stepws-5.2.2-648290.xsd stepws-5.2.1-610503.xsd
stepws-5.2.2-648291.xsd > stepws.merged
diff -u stepws-5.2.1-610503.xsd stepws.merged
Using the files you provided, I've verified that if you first cherry-pick
the change which adds the "bad block", and then cherry-pick the change
which adds the "good-block", there is no conflict.
Does this explanation make sense?
Re: merge disagrees with diff
On Fri, 28 Oct 2011 13:02:05 +, Flemming Frandsen wrote: ... > The problem is that there are many more changes in the conflicted > block than the diff suggested, iow: svn merge tried to add more lines > than svn diff said it would. That only looks like that because of the way merging is described in the book. It is true that if you merge the change from A to B into C and get D, then diff(A,B) should be the same as diff(C,D). But this holds only when there are no conflicts. Example. A is: one two three four five six seven Add a line to get B: one two three three two thirds four five six seven Meanwhile for C we have removed a few lines: one two three six seven And now we merge the diff(A,B) onto C and get: one two three <<< HEAD === three two thirds four five >>> work six seven which means it looks like the merge is bringing in 'too much', but what it is actually showing is that between the lines 'three' and 'seven' that were in the baseline version of the file (A) there are no lines left in C and three lines, partially 'new', in B. In essence, svn sees only two different (and conflicting) changes to a block of lines, and leaves it to you to deal with that. (Likewise do git and CVS.) This looks pretty much like your situation. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: update --depth=empty ignored since 1.7
Mojca Miklavec writes: > I'm experiencing some weird behaviour with SVN 1.7. The following > sequence of commands fails to respect --depth=empty: > svn co --depth=empty http://foundry.supelec.fr/svn/metapost > svn up --depth=empty metapost/tags > > (you can use 'anonymous' as a username) The first command runs fine, > but the second one starts fetching all tags. If I try to open > repository in web browser, it reports that the server is using SVN > 1.4.2 (r22196) which is a bit old, but with SVN 1.6.16 the same > sequence of commands worked fine - depth=empty seems to be respected. That certainly looks like a 1.7 bug, I've raised issue 4046 http://subversion.tigris.org/issues/show_bug.cgi?id=4046 -- Philip
update --depth=empty ignored since 1.7
Dear list, I'm experiencing some weird behaviour with SVN 1.7. The following sequence of commands fails to respect --depth=empty: svn co --depth=empty http://foundry.supelec.fr/svn/metapost svn up --depth=empty metapost/tags (you can use 'anonymous' as a username) The first command runs fine, but the second one starts fetching all tags. If I try to open repository in web browser, it reports that the server is using SVN 1.4.2 (r22196) which is a bit old, but with SVN 1.6.16 the same sequence of commands worked fine - depth=empty seems to be respected. I cannot reproduce the behaviour with http://svn.apache.org/repos/asf/subversion where the same commands work just fine. Is this a bug in SVN client 1.7.(0/1) or my misunderstanding of how the above commands are supposed to work? I noticed that some depth=empty-related issues are mentioned in changelog for 1.7.1, but subversion 1.7.1 as shipped with MacPorts on Mac OS X 10.7 doesn't seem to behave any differently. Thank you very much, Mojca
Re: merge disagrees with diff
On Fri, Oct 28, 2011 at 12:58 PM, Andreas Krey wrote: > You didn't get a clean merge; you got a conflict. When you get a conflict, > it is your job to look at what you merged and at the proposed result, > and resolve it yourself. Yes, I have seen conflicts before, that's not what the problem is, I know how to handle conflicts. > (Can't tell without the three versions that have been requested.) Those versions were sent to the developer who requested them, I'd rather not have them on the public mailing list. The problem is that there are many more changes in the conflicted block than the diff suggested, iow: svn merge tried to add more lines than svn diff said it would. -- Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: merge disagrees with diff
On Fri, 28 Oct 2011 12:49:35 +, Flemming Frandsen wrote: ... > This is not the only time I've seen the problem manifest, but the > circumstances where similar, in the other case another developer was > trying to merge a change from version-1 to version-2, he too got extra > changes in his merge target. You didn't get a clean merge; you got a conflict. When you get a conflict, it is your job to look at what you merged and at the proposed result, and resolve it yourself. Here it may simply be that you get the conflict because you want to merge in the addition of a block of code but in the merge target surrounding (here: following) blocks have been removed. Now you get all of those within the conflict marker. (Can't tell without the three versions that have been requested.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: merge disagrees with diff
On Fri, Oct 28, 2011 at 12:31 PM, Johan Corveleyn wrote: > Here is something I don't understand. You just did a new checkout to > someotherpath. The HEAD of your repository is at least 648291. How > come that someotherpath/stepws.xsd is at revision 610503? That doesn't > make sense. I'm sorry, I cheated a tiny bit, the merge target was made using "svn co -r 610503" to get the exact version where we first saw the problem, that was needed because changes have been made in that branch since we first saw the problem. I can assure you the problem is exactly the same as originally (without -r) and shows up with a clean checkout. To make it less obscure, you can replace "somepath" with "/branch/version-2" and "someotherpath" with "/branch/version-1". In other words, what I'm trying to do is to backport a change from version-2 to version-1, both version-1 and version-2 were forked off from trunk. The extra change in the target file appears the change just before the wanted change in the source file (iow: it appears that the svn merge command did what I would have expected if I had used svn merge -c 625829,648291 ... in stead of svn merge -c 648291 ...): svn diff -c 625829 svn+ssh://myserver/somepath/stepws.xsd Index: stepws.xsd === --- stepws.xsd (revision 625828) +++ stepws.xsd (revision 625829) @@ -366,6 +366,42 @@ + + + + + + +username and password for the user to access STEP as, and the URLs of the context and +workspace to access data through. + + + + + +URL of the LOV to obtain values from + + + + +The list of LOV values to add + + + + + + + + + + +The new list of LOV values + + + + + + > Are you sure that the merge target (someotherpath) was a clean > checkout, with nothing locally modified? Absolutely. > The only explanation (short of a bug in 'merge') I can come up with > for this behavior, is if someotherpath/stepws.xsd was already modified > in the working copy (already containing those extra added lines that > suddenly seemed to appear here). It did not, it's a completely clean checkout, done from scratch. This is not the only time I've seen the problem manifest, but the circumstances where similar, in the other case another developer was trying to merge a change from version-1 to version-2, he too got extra changes in his merge target. -- Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: tortoise 1.7 - error on repository manipulation
Le 28/10/2011 10:51, Daniel Shahaf a écrit : Erwane, can you provide a minimal server configuration that reproduces the bug? The svn devs used 1.7 clients against a 1.6.17 svn.apache.org for a long time without seeing any such errors, so I suspect the issue is due to your configuration triggering some edge case. I'm doing that on a virtualbox, taking a time :) Le 28/10/2011 11:00, Philip Martin a écrit : That's a v2 protocol problem. The v2 protocol is only used when both client and server are 1.7. If you add "SVNAdvertiseV2Protocol off" to the 1.7 Apache config file then clients should use the v1 protocol. Do the error messages really have two '*' characters in the URL or is that an email artifact? Is your 1.7 server a write-through proxy to a 1.6 master? That won't work unless you disable the v2 protocol because the 1.6 master will not understand the v2 protocol. Is there some proxy or filter between the client and server that is corrupting the ULR? There is no * ine the message, it's "bold" format. real message is : /svn/site/!svn/me path not found On my new server, i'm using : - apache-2.2.21 - apache-ant-1.8.2_1 - apr-ipv6-devrandom-gdbm-db48-mysql55-1.4.5.1.3.12_1 - p5-subversion-1.7.1 - subversion-1.7.1 So, the subversion server is 1.7.1 and client is 1.7.1 too :) i've tried to create an new fresh repository on my server, gived the good rights and do the first commit. same error. The only proxy is apache + mod_dav. mod_deflate and mod_ssl too, but when i deactivating them, it's the same. Le 28/10/2011 11:41, Stefan Sperling a écrit : A shot in the dark: Is it possible that you accidentally loaded mod_dav_svn from Subversion 1.7 and mod_authz_svn from Subversion 1.6? Because this looks as if the client thinks the server supports HTTPv2, but the server does not actually support it. Which is weird, because mod_dav_svn apparently negotiated HTTPv2 with the client, so it should work. The only possible explanation I can come up with is that parts of your server are running 1.6 code, and other parts are running 1.7 code. No, because i do a fresh install and rebuild everything since. I will retry to rebuild. The install of my virtualbox, for Daniel Shahaf, maybe solved the problem, in local. If it's work with minimal configuration, something goes wrong in my apache config. Thanks everyone for helping me :) -- Erwane Breton Phea Tel: 09 51 20 23 23 Mob: 06 76 46 54 61
Re: merge disagrees with diff
On Fri, Oct 28, 2011 at 11:55 AM, Flemming Frandsen wrote: > We're having a major problem with subversion, it seems that for some > changesets svn merge will do a different change than svn diff would > suggest. > > Here's an example of that the problem looks like: > > > svn diff -c 648291 svn+ssh://myserver/somepath/stepws.xsd > > Index: stepws.xsd > === > --- stepws.xsd (revision 648290) > +++ stepws.xsd (revision 648291) > @@ -366,6 +366,37 @@ > > type="tns:getLOVValueIDsResponseType"/> > > + > + > + > + > + > + > + username and password for the user > to access STEP as, and the URLs of the context and > + workspace to access data through. > + > + > + > + > + > + URL of the asset to obtain system > values from > + > + > + > + > + type="tns:getAssetSystemValuesRequestType"/> > + > + > + > + maxOccurs="unbounded"> > + > + The attribute values > + > + > + > + > + type="tns:getAssetSystemValuesResponseType"/> > + > > > > Now I tried to check out an older branch to backport that change: >> svn co svn+ssh://myserver/someotherpath >> cd someotherpath >> svn merge -c 648291 svn+ssh://myserver/somepath/stepws.xsd stepws.xsd > Conflict discovered in 'stepws.xsd'. > Select: (p) postpone, (df) diff-full, (e) edit, > (mc) mine-conflict, (tc) theirs-conflict, > (s) show all options: p > --- Merging r648291 into 'stepws.xsd': > C stepws.xsd > Summary of conflicts: > Text conflicts: > > >> svn diff > > > Index: stepws.xsd > === > --- stepws.xsd (revision 610503) Here is something I don't understand. You just did a new checkout to someotherpath. The HEAD of your repository is at least 648291. How come that someotherpath/stepws.xsd is at revision 610503? That doesn't make sense. Are you sure that the merge target (someotherpath) was a clean checkout, with nothing locally modified? The only explanation (short of a bug in 'merge') I can come up with for this behavior, is if someotherpath/stepws.xsd was already modified in the working copy (already containing those extra added lines that suddenly seemed to appear here). -- Johan > +++ stepws.xsd (working copy) > @@ -366,6 +366,76 @@ > > type="tns:getLOVValueIDsResponseType"/> > > +<<< .working > +=== > + > + > + > + > + > + > + username and password for the user > to access STEP as, and the URLs of the context and > + workspace to access data through. > + > + > + > + > + > + URL of the asset to obtain system > values from > + > + > + > + > + type="tns:getAssetSystemValuesRequestType"/> > + > + > + > + maxOccurs="unbounded"> > + > + The attribute values > + > + > + > + > + type="tns:getAssetSystemValuesResponseType"/> > + > + > + > + > + > + > + > + username and password for the user > to access STEP as, and the URLs of the context and > + workspace to access data through. > + > + > + > + > + > + URL of the LOV to obtain values > from > + > + > + maxOccurs="unbounded"> > + > + The list of LOV values to > add > + > + > + > + > + type="tns:addLOVValueIDsRequestType"/> > + > + > + > + minOccurs="0" maxOccurs="unbounded"> > + > + The new list of LOV values > + > + > + > + > + type="tns:addLOVValueIDsResponseType"/> > + > +>>> .merge-right.r648291 > > > > > > As you can see the resulting change to the checked out file after > merge is different from the change reported by diff. > > I've found this problem on 1.6.12 and reproduced it with a > home-compiled 1.7.1, the server runs ubuntu server 10.10. > > Clients are mostly linux with mostly 1.6.12, but there are windows > machines and 1.7.1 clients as well. > > I did not find any --dont-merge-random-crap option, so I'm very confused. > > -- > Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/ >
Re: merge disagrees with diff
Am 28.10.2011 11:55, schrieb Flemming Frandsen: We're having a major problem with subversion, it seems that for some changesets svn merge will do a different change than svn diff would suggest. It took me a while of scrolling up and down to find the difference, but IIUC the problem is A) that there is a conflict and B) that the added code contains the stuff following the "addLOVValueIDs" comment. A few things I noticed: - In trunk, the text was added to the end of the file, while in the branch it seems to have been merged into the middle somewhere. Question is where should it have been applied? You might be hitting some limitations of the merge algorithm here, too. - You mentioned that you have clients on different OS families. I know that SVN is a bit picky when things like line endings differ between source and target of a merge. I've repeatedly had whole files that were reported as conflicting because of that. If the line endings are even mixed within a file, different, unpleasant things could happen. In my case it was caused by setting svn:eol-style in the trunk and then merging to the branch without svn:eol-style. - Another way to mess with lineendings is to check out on one system and then use that working copy on another. Typically that happens when putting the WCs on a shared directory or when using it with Cygwin and MS Windows. I did not find any --dont-merge-random-crap option, so I'm very confused. How confused would you be if you had found that option? ;D Uli ** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden. E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich. **
Re: merge disagrees with diff
On Fri, Oct 28, 2011 at 11:55:06AM +0200, Flemming Frandsen wrote: > We're having a major problem with subversion, it seems that for some > changesets svn merge will do a different change than svn diff would > suggest. This does indeed look like a bug in merge. Is it possible for you to provide the following files? >From merge source: stepws.xsd@648290 stepws.xsd@648291 >From merge target: stepws.xsd@610503 If necessary, you can email them in private and I promise to only share them among Subversion developers for debugging purposes.
merge disagrees with diff
We're having a major problem with subversion, it seems that for some changesets svn merge will do a different change than svn diff would suggest. Here's an example of that the problem looks like: svn diff -c 648291 svn+ssh://myserver/somepath/stepws.xsd Index: stepws.xsd === --- stepws.xsd (revision 648290) +++ stepws.xsd (revision 648291) @@ -366,6 +366,37 @@ + + + + + + +username and password for the user to access STEP as, and the URLs of the context and +workspace to access data through. + + + + + +URL of the asset to obtain system values from + + + + + + + + + + +The attribute values + + + + + + Now I tried to check out an older branch to backport that change: > svn co svn+ssh://myserver/someotherpath > cd someotherpath > svn merge -c 648291 svn+ssh://myserver/somepath/stepws.xsd stepws.xsd Conflict discovered in 'stepws.xsd'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: p --- Merging r648291 into 'stepws.xsd': Cstepws.xsd Summary of conflicts: Text conflicts: > svn diff Index: stepws.xsd === --- stepws.xsd (revision 610503) +++ stepws.xsd (working copy) @@ -366,6 +366,76 @@ +<<< .working +=== + + + + + + +username and password for the user to access STEP as, and the URLs of the context and +workspace to access data through. + + + + + +URL of the asset to obtain system values from + + + + + + + + + + +The attribute values + + + + + + + + + + + + +username and password for the user to access STEP as, and the URLs of the context and +workspace to access data through. + + + + + +URL of the LOV to obtain values from + + + + +The list of LOV values to add + + + + + + + + + + +The new list of LOV values + + + + + + +>>> .merge-right.r648291 As you can see the resulting change to the checked out file after merge is different from the change reported by diff. I've found this problem on 1.6.12 and reproduced it with a home-compiled 1.7.1, the server runs ubuntu server 10.10. Clients are mostly linux with mostly 1.6.12, but there are windows machines and 1.7.1 clients as well. I did not find any --dont-merge-random-crap option, so I'm very confused. -- Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
Re: tortoise 1.7 - error on repository manipulation
On Thu, Oct 27, 2011 at 04:19:54PM +0200, Erwane Breton wrote: > The error is always the same > > >Commit > >Commit failed (details follow): > >'/svn/site/*!svn/me*' path not found > > > My repository is https://xyz.coda-cola.net/svn/site/trunk > > I've tried svnadmin upgrade, exactly the same. > > apache debug error logs (without openSSL informations) A shot in the dark: Is it possible that you accidentally loaded mod_dav_svn from Subversion 1.7 and mod_authz_svn from Subversion 1.6? Because this looks as if the client thinks the server supports HTTPv2, but the server does not actually support it. Which is weird, because mod_dav_svn apparently negotiated HTTPv2 with the client, so it should work. The only possible explanation I can come up with is that parts of your server are running 1.6 code, and other parts are running 1.7 code. > >[Thu Oct 27 14:58:57 2011] [info] Connection: Client IP: > >82.226.xxx.xxx, Protocol: SSLv3, Cipher: DHE-RSA-AES256-SHA > >(256/256 bits) > >[Thu Oct 27 14:58:57 2011] [info] Initial (No.1) HTTPS request > >received for child 0 (server xyz.coda-cola.net:443) > >[Thu Oct 27 14:58:57 2011] [debug] > >subversion/mod_authz_svn/mod_authz_svn.c(193): [client > >82.226.xxx.xxx] Path to authz file is > >/exports/svn/xyz/authorizations.conf > >[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client > >82.226.xxx.xxx] Zlib: Compressed 401 to 272 : URL /svn/site/trunk > >[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.2) HTTPS request > >received for child 0 (server xyz.coda-cola.net:443) > >[Thu Oct 27 14:58:57 2011] [debug] > >subversion/mod_authz_svn/mod_authz_svn.c(193): [client > >82.226.xxx.xxx] Path to authz file is > >/exports/svn/xyz/authorizations.conf > >[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access > >granted: 'erwane' OPTIONS site:/trunk > >[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client > >82.226.xxx.xxx] Zlib: Compressed 188 to 126 : URL /svn/site/trunk > >[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.3) HTTPS request > >received for child 0 (server xyz.coda-cola.net:443) > >[Thu Oct 27 14:58:57 2011] [debug] > >subversion/mod_authz_svn/mod_authz_svn.c(193): [client > >82.226.xxx.xxx] Path to authz file is > >/exports/svn/xyz/authorizations.conf > >[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access > >granted: 'erwane' POST site: > >[Thu Oct 27 14:59:00 2011] [debug] mod_deflate.c(615): [client > >82.226.xxx.xxx] Zlib: Compressed 484 to 354 : URL > >/svn/site/*!svn/me*
Re: Assertion failed and crash with 1.7.1
Attila Nagy writes: > ZFS. > It it worth to make benchmarks with this WC with 1.6 and 1.7? I so, I > can try to find the time for it. There are some reports that a mismatch between SQLite page size and ZFS block size can cause performance problems and that better performance is obtained when they match: http://osdir.com/ml/sqlite-users/2010-10/msg00582.html http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg20395.html If you build Subversion from source we could try changing the SQLite page size. -- Philip
Re: tortoise 1.7 - error on repository manipulation
Erwane Breton writes: > On my client (windows 7 x64 tortoise SVN), i CAN commit with Tortoise > 1.6.15 on my laptop but i CAN'T commit (or rename or delete) on my > other computer with tortoise 1.7.1.22161 > > The error is always the same > >> Commit >> Commit failed (details follow): >> '/svn/site/*!svn/me*' path not found >> [Thu Oct 27 14:59:00 2011] [debug] mod_deflate.c(615): [client >> 82.226.xxx.xxx] Zlib: Compressed 484 to 354 : URL >> /svn/site/*!svn/me* That's a v2 protocol problem. The v2 protocol is only used when both client and server are 1.7. If you add "SVNAdvertiseV2Protocol off" to the 1.7 Apache config file then clients should use the v1 protocol. Do the error messages really have two '*' characters in the URL or is that an email artifact? Is your 1.7 server a write-through proxy to a 1.6 master? That won't work unless you disable the v2 protocol because the 1.6 master will not understand the v2 protocol. Is there some proxy or filter between the client and server that is corrupting the ULR? -- Philip
Re: tortoise 1.7 - error on repository manipulation
Daniel Shahaf wrote on Thu, Oct 27, 2011 at 22:12:46 +0200: > Does it work with a 1.6 client? > dcz, thanks. Erwane, can you provide a minimal server configuration that reproduces the bug? The svn devs used 1.7 clients against a 1.6.17 svn.apache.org for a long time without seeing any such errors, so I suspect the issue is due to your configuration triggering some edge case. > The me resource is new in HTTPv2, which was added in 1.6. > > Erwane Breton wrote on Thu, Oct 27, 2011 at 16:19:54 +0200: > > Hi, > > > > history : > > I haved a FreeBSD server (8.0-STABLE) with subversion-1.6.17_2 port. > > Acces to repository is configured thrue apache 2.2 + mod_dav + dav_svn. > > Of course, all works fine :) > > > > I've got a new server on FreeBSD 8.2-STABLE with subversion-1.7.1, > > apache, mod_dav & dav_svn. > > All works fine ... in checkout and update. > > > > For migration, i've make first a rsync only, when i saw the error > > (cf bottom) i've made that more cleanly with svnadmin dump and > > svnadmin load. > > In both cases, result is the same. > > > > Now the error ^^ > > > > On my client (windows 7 x64 tortoise SVN), i CAN commit with > > Tortoise 1.6.15 on my laptop but i CAN'T commit (or rename or > > delete) on my other computer with tortoise 1.7.1.22161 > > > > The error is always the same > > > > >Commit > > >Commit failed (details follow): > > >'/svn/site/*!svn/me*' path not found > > > > > My repository is https://xyz.coda-cola.net/svn/site/trunk > > > > I've tried svnadmin upgrade, exactly the same. > > > > apache debug error logs (without openSSL informations) > > > > >[Thu Oct 27 14:58:57 2011] [info] Connection: Client IP: > > >82.226.xxx.xxx, Protocol: SSLv3, Cipher: DHE-RSA-AES256-SHA > > >(256/256 bits) > > >[Thu Oct 27 14:58:57 2011] [info] Initial (No.1) HTTPS request > > >received for child 0 (server xyz.coda-cola.net:443) > > >[Thu Oct 27 14:58:57 2011] [debug] > > >subversion/mod_authz_svn/mod_authz_svn.c(193): [client > > >82.226.xxx.xxx] Path to authz file is > > >/exports/svn/xyz/authorizations.conf > > >[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client > > >82.226.xxx.xxx] Zlib: Compressed 401 to 272 : URL /svn/site/trunk > > >[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.2) HTTPS request > > >received for child 0 (server xyz.coda-cola.net:443) > > >[Thu Oct 27 14:58:57 2011] [debug] > > >subversion/mod_authz_svn/mod_authz_svn.c(193): [client > > >82.226.xxx.xxx] Path to authz file is > > >/exports/svn/xyz/authorizations.conf > > >[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access > > >granted: 'erwane' OPTIONS site:/trunk > > >[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client > > >82.226.xxx.xxx] Zlib: Compressed 188 to 126 : URL /svn/site/trunk > > >[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.3) HTTPS request > > >received for child 0 (server xyz.coda-cola.net:443) > > >[Thu Oct 27 14:58:57 2011] [debug] > > >subversion/mod_authz_svn/mod_authz_svn.c(193): [client > > >82.226.xxx.xxx] Path to authz file is > > >/exports/svn/xyz/authorizations.conf > > >[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access > > >granted: 'erwane' POST site: > > >[Thu Oct 27 14:59:00 2011] [debug] mod_deflate.c(615): [client > > >82.226.xxx.xxx] Zlib: Compressed 484 to 354 : URL > > >/svn/site/*!svn/me* > > > > After googled, i've found only "no space left on disk" but my ZFS > > volume is completely not full. > > > > just tried without SSL, it's the same. > > > > really dunno where to search now :( > > > > Thanks for help > > > > -- > > Erwane Breton > > Phea > > Tel: 09 51 20 23 23 > > Mob: 06 76 46 54 61 > >
Re: How to move a Repository and its associated folder to a new server
Ulrich Eckhardt wrote on Fri, Oct 28, 2011 at 08:42:30 +0200: > Am 27.10.2011 23:56, schrieb Big George: > >What I try to do is to move my Repository and folder D:\Scripts_DB > >(with all its changes ) from PC1 to PC2. > > There are two things involved for moving the repo: > 1. Moving the repo itself > A simple file-system copy would do the job. This method may not work in the general case. (Specifically, the on-disk format of BDB databases depends on the architecture.)
Re: tortoise 1.7 - error on repository manipulation
Le jeudi 27 octobre 2011 22:12:46, Daniel Shahaf a écrit : Does it work with a 1.6 client? Erwane Breton wrote on Thu, Oct 27, 2011 at 16:19:54 +0200: i CAN commit with Tortoise 1.6.15 I guess he can.
