RE: Release Repositories
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com] > On Mon, Nov 22, 2010 at 9:55 PM, Andrey Repin > > Cron job won't be able to know if file transfer is completed. It > > will have to guess from, e.g., testing the archive (if it's > > archive) for integrity. filesystem notification mechanism will > > for sure know, when the iostream got filewriteclose event. > > One of the more helpful tricks is to check if it's newer than a > certain period, and *older* than a certtain, modest period (such > as a few minutes) to make sure the transfer is complete. The "magic touch file" approach: touch a file timestamp.txt and then do "find -newer touchfile.txt". You could also rsync the directory in question to another one you have control on, and which is an svn working copy, and then have some job do a commit when rsync has finished synching. Not familiar with the name, I looked up Rube Goldberg, and yeah, exactly :-) Michael
Should svn allow a merge into a conflicted file?
Should Subversion allow a merge on top of a file that already contains an unresolved conflict? Run the script below to set up the scenario. The first merge introduces a conflict, the second merge contains incoming changes to the conflicting section. The second merge is applied successfully to the working copy. However, as the working copy is still in conflict, when you come to resolve it, the contributors overwrite the later changes. In the example, the contributors are foo.c.working, foo.c.merge-right.r4 and foo.c.merge-left.r3. When the merge is completed the foo.c that had contained the changes from the second merge are overwritten. I think it's a misfeature that svn allows a merge into a file that already contains conflicts, especially given that multiple pass merges are broken up for entirely the reason that there is no reliable way to merge a change into a file that already contains conflicts. It may seem unlikely that someone would do a second merge when there is already conflicts, however this is the case when you pick two separate source revisions to merge in Tortoise, and then choose to postone resolving all conflicts - you may not realise there is a conflict in the first revision as subsequent revisions may be merged successfully. Apparently it is documented that you must resolve interactively when cherrypicking, however I can't find this. Nevertheless, imho the behaviour in this scenario should be the same as when merging a non-contiguous range of revisions, ie you are forced to resolve conflicts after each sub-range. Grateful for any opinions on this... and if this is a reported bug, what's the ID please. cheers, jamie __SCRIPT__ @rem config SET REPO_PATH=file:///c:/tmp/TestMergeIssue/repo rm -rf wc repo svnadmin create repo svn co %REPO_PATH% wc pushd wc mkdir trunk branches echo 1 >> trunk\foo.c echo 2 >> trunk\foo.c echo 3 >> trunk\foo.c echo 4 >> trunk\foo.c echo 5 >> trunk\foo.c echo 6 >> trunk\foo.c echo 7 >> trunk\foo.c echo 8 >> trunk\foo.c echo 9 >> trunk\foo.c svn add trunk branches svn commit -m "1" svn cp trunk branches/1.0 svn commit -m "2" @rem change 2nd line on trunk perl -pi.bak -e "s/2/B trunk/" trunk/foo.c svn commit -m "3" trunk/foo.c @rem add lines on branch perl -pi.bak -e "s/2/A.ny\nB.ny\nC.ny\nD.ny/" branches/1.0/foo.c svn commit -m "4" branches/1.0/foo.c @rem this will conflict now @rem modify two of the lines on branch perl -pi.bak -e "s/C.ny/C/" branches/1.0/foo.c perl -pi.bak -e "s/D.ny/D/" branches/1.0/foo.c svn commit -m "5" branches/1.0/foo.c pushd trunk svn merge --accept postpone -c 4 ^^/branches/1.0 svn merge --accept postpone -c 5 ^^/branches/1.0 popd popd === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===
Find file in repo
Hi all, How can I get the path of one file in a SVN repo?Supouse I want to find a file named "LoginInterceptor.c" with its complete path in one SVN repo. Thanks in advanced. ///RGB
Re: Find file in repo
On 23-11-2010 12:49, Gerardo Corro wrote: How can I get the path of one file in a SVN repo? Supouse I want to find a file named "LoginInterceptor.c" with its complete path in one SVN repo. Hi, maybe it's not exactly what you are asking for, but try to use something like this: svn ls -R svn://svnserver/repo | grep LoginInterceptor.c -- Piotr Kabacinski a2Fib3Q=
file externals & URLs
Hi, I read in the svn-book that file externals are supported only in the same repository. But it is not clear in my repositories architecture : My repositories are accessed through Apache and all use the same FQDN/vhost. FQDN/repo1 FQDN/repo2 \ | \ | \ / \ / \ / VHOST (FQDN) | | / \ / \ / \ | | | | repo1 repo2 Is it still not possible to use file externals pointing on different repositories ? According to the documentation I think it is not possible, but I prefer ask for confirmation. -- Bastien Semene Administrateur Réseau& Système Cyanide Studio - FRANCE
Re: file externals & URLs
Hi, Externals to different repositories are possible. http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html You can use relative path when accessing the same repository. Problem is if you want to point to file (not to directory) - that, in fact, is not possible. greetings On 23-11-2010 14:43, Bastien Semene wrote: Hi, I read in the svn-book that file externals are supported only in the same repository. But it is not clear in my repositories architecture : My repositories are accessed through Apache and all use the same FQDN/vhost. FQDN/repo1 FQDN/repo2 \ | \ | \ / \ / \ / VHOST (FQDN) | | / \ / \ / \ | | | | repo1 repo2 Is it still not possible to use file externals pointing on different repositories ? According to the documentation I think it is not possible, but I prefer ask for confirmation. -- Piotr Kabacinski a2Fib3Q=
Re: file externals & URLs
On Tue, Nov 23, 2010 at 8:43 AM, Bastien Semene wrote: > Hi, > > I read in the svn-book that file externals are supported only in the same > repository. But it is not clear in my repositories architecture : > > My repositories are accessed through Apache and all use the same FQDN/vhost. So, you have multiple repositories on the same host? No, each repository has its own database and is distinct even though they maybe on the same host and even in the same Apache instant. However, I've usually find that externals aren't really worth the effort it takes to really support them. Let's say you have a project "foo" which is http://FQDN/repo1/foo/trunk, and it is using as an external project http://FSND/repo1/bar/trunk. So, you create the following external: $ svn propset svn:externals http://FQDN/repo1/bar/trunk bar Everything is fine, and you're ready to do a release of foo: $ svn cp http://FQND/repo1/foo/trunk http://FQND/repo1/foo/tags/FOO-1.0 However, all is not well. Your tag is not static because whenever http://FQND/repo1/bar/trunk changes, the files you'd checkout under FOO-1.0 will change. That's because your svn:externals property points to the trunk of bar, and not to a particular revision. If you need to create a new release FOO-1.0.1 based upon FOO-.1.0, the files under bar would not be what you think they are. In order to get around this, you need to point your svn:externals property in foo to a particular revision of bar. This could be a tagged revision (although in theory tags can change, but not likely). Or to an actual revision of bar (using the -r parameter). Also, you may want to peg bar to that revision while you're at it. Otherwise, the directory structure of bar could change, and that would affect your tag of foo. Thus, when you create the external, you really should do something like this: $ svn propset svn:externals -r1000 ^/repo1/bar/tr...@1000 bar This will freeze your svn:externals project at revision 1000 of your repository, and make sure that the way the bar directory looks the same as it did at revision 1000. Another thing I've seen is from sites where the trunk, branches, and tags directories are all on the root of the repository. Thus the URL for FOO would be: http://FQDN/repo1/trunk/foo http://FQDN/repo1/tags/foo/FOO-1.0 and the URL for BAR would be: http://FQDN/repo1/trunk/bar http://FQDN/repo1/tags/bar/FOO-1.0 In this case, you could set the svn:externals like this: $ svn propset svn:externals ../../bar bar This way, the branching and tagging schemes of BAR and FOO will match even when you do a URL copy and create new branches and tags (as long as both FOO and BAR have the same branches and tags setup). I find the best way is to just make BAR a releasable subproject. You could zip up its source code or compile bar into some sort of object file that FOO can use (a jarfile for a Java project, or a *.dll or *.so for C or C++ projects). Then, I'd have my build file copy the correct version of bar down from the release repository as part of my build process. That way, you don't have to maintain svn:externals, or be limited by the fact that svn:externals projects have to live in the same repository as the master project. The svn:externals seemed like such a good idea when I first heard of Subversion, but I quickly discovered that it can be very difficult to implement correctly. -- David Weintraub qazw...@gmail.com
Re: Find file in repo
On Tue, Nov 23, 2010 at 7:06 AM, Piotr Kabacinski wrote: > Hi, maybe it's not exactly what you are asking for, but try to use something > like this: > svn ls -R svn://svnserver/repo | grep LoginInterceptor.c If you're on Windows, you can use "find" instead of "grep" $ svn ls -R svn://svnserver/repo | find "LoginInterceptor.c" -- David Weintraub qazw...@gmail.com
Re: file externals & URLs
On 11/23/10 7:52 AM, Piotr Kabacinski wrote: Hi, Externals to different repositories are possible. http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html You can use relative path when accessing the same repository. Problem is if you want to point to file (not to directory) - that, in fact, is not possible. But depending on the layout you need, you might be able to move the file you want into a containing directory which you can reference. Or just ignore the rest of what you get if you pull the whole directory it is already in. -- Les Mikesell lesmikes...@gmail.com
Re: file externals & URLs
Yes, I have different repositories hosted by the same Apache vhost (with the SVNParentPath directive), and I can use relative paths to make externals of folders between different repositories (different databases). And they actually are on different hosts thanks to NFS. From Piotr Kabacinski response (I compiled the mails) "You can use relative path when accessing the same repository" This is exactly the ambiguous use of terms I'm talking about. I can think that I can't use svn:externals on different repositories, but I can if they have the same FQDN (I think we're currently using 20-30 externals of this kind). My question is, is there an ambiguous use of terms in the svn-book ? I can't find any reference on the multi-HTML book. They are some in the single-HTML : http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals It is said "File externals are configured just like externals for directories and appear as a versioned file in the working copy" It is a bit more explicit than the PDF version I read before posting. The best way is, I think, to test it. I'll answer with my results. P.S. : The rest of your mail is slightly out of the scope of my question, but in our case the "freezers (i.e. project managers)" have the choice to manually edit svn:externals properties or use built externals librairies. This choice is mostly dependent on the persons. Le 23/11/2010 15:09, David Weintraub a écrit : On Tue, Nov 23, 2010 at 8:43 AM, Bastien Semene wrote: Hi, I read in the svn-book that file externals are supported only in the same repository. But it is not clear in my repositories architecture : My repositories are accessed through Apache and all use the same FQDN/vhost. So, you have multiple repositories on the same host? No, each repository has its own database and is distinct even though they maybe on the same host and even in the same Apache instant. However, I've usually find that externals aren't really worth the effort it takes to really support them. Let's say you have a project "foo" which is http://FQDN/repo1/foo/trunk, and it is using as an external project http://FSND/repo1/bar/trunk. So, you create the following external: $ svn propset svn:externals http://FQDN/repo1/bar/trunk bar Everything is fine, and you're ready to do a release of foo: $ svn cp http://FQND/repo1/foo/trunk http://FQND/repo1/foo/tags/FOO-1.0 However, all is not well. Your tag is not static because whenever http://FQND/repo1/bar/trunk changes, the files you'd checkout under FOO-1.0 will change. That's because your svn:externals property points to the trunk of bar, and not to a particular revision. If you need to create a new release FOO-1.0.1 based upon FOO-.1.0, the files under bar would not be what you think they are. In order to get around this, you need to point your svn:externals property in foo to a particular revision of bar. This could be a tagged revision (although in theory tags can change, but not likely). Or to an actual revision of bar (using the -r parameter). Also, you may want to peg bar to that revision while you're at it. Otherwise, the directory structure of bar could change, and that would affect your tag of foo. Thus, when you create the external, you really should do something like this: $ svn propset svn:externals -r1000 ^/repo1/bar/tr...@1000 bar This will freeze your svn:externals project at revision 1000 of your repository, and make sure that the way the bar directory looks the same as it did at revision 1000. Another thing I've seen is from sites where the trunk, branches, and tags directories are all on the root of the repository. Thus the URL for FOO would be: http://FQDN/repo1/trunk/foo http://FQDN/repo1/tags/foo/FOO-1.0 and the URL for BAR would be: http://FQDN/repo1/trunk/bar http://FQDN/repo1/tags/bar/FOO-1.0 In this case, you could set the svn:externals like this: $ svn propset svn:externals ../../bar bar This way, the branching and tagging schemes of BAR and FOO will match even when you do a URL copy and create new branches and tags (as long as both FOO and BAR have the same branches and tags setup). I find the best way is to just make BAR a releasable subproject. You could zip up its source code or compile bar into some sort of object file that FOO can use (a jarfile for a Java project, or a *.dll or *.so for C or C++ projects). Then, I'd have my build file copy the correct version of bar down from the release repository as part of my build process. That way, you don't have to maintain svn:externals, or be limited by the fact that svn:externals projects have to live in the same repository as the master project. The svn:externals seemed like such a good idea when I first heard of Subversion, but I quickly discovered that it can be very difficult to implement correctly. -- Bastien Semene Administrateur Réseau& Système Cyanide Studio - FRANCE
RE: file externals & URLs
> From: Piotr Kabacinski [mailto:pi...@kabot.net] > Externals to different repositories are possible. > http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html > You can use relative path when accessing the same repository. > > Problem is if you want to point to file (not to directory) - that, in > fact, is not possible. It isn't possible in 1.5, but it is in 1.6. Michael
Re: file externals & URLs
On 23-11-2010 15:46, Bastien Semene wrote: From Piotr Kabacinski response (I compiled the mails) "You can use relative path when accessing the same repository" This is exactly the ambiguous use of terms I'm talking about. I can think that I can't use svn:externals on different repositories, but I can if they have the same FQDN (I think we're currently using 20-30 externals of this kind). My question is, is there an ambiguous use of terms in the svn-book ? I can't find any reference on the multi-HTML book. They are some in the single-HTML : http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals The ambiguity you see is maybe becouse you can use svn:externals on different and the same repositories using absolute and relative paths. -- Piotr Kabacinski a2Fib3Q=
Diff tag against trunk head
Hello, I am using the latest (stable) version on both Linux and WinSlows. For one of my repositories, I created a daily tag of a diary. Example: /project/trunk/important_stuff /project/tags/2010-11-20/important_stuff /project/tags/2010-11-21/important_stuff /project/tags/2010-11-22/important_stuff etc. Each morning I svn copy "important_stuff" (HEAD revision) to the tags area and commit. In theory, this will be used to easily find what changed day-over-day. Of course all of this is possible poking through svn logs, but I want to make this easier. My question: What is the SVN command to diff a file in a tagged set vs trunk head? Fantasy command: svn diff -r"tag:2010-11-21" -rHEAD /project/trunk/important_stuff/details.txt or... svn diff -r"trunk:HEAD" /project/tags/2010-11-21/important_stuff/details.txt I tried many different svn diff commands. No luck. I also did some heavy Google/StackOverflow searching. No luck. Is there a simple way to do this? Right now I am using regular GNU diff, but this requires everyone to download the tags to their box locally. Ideally, this could be done via the trunk or tag URL only. Thanks, Arpe Hongkong
Re: file externals & URLs
On 11/23/2010 8:09 AM, David Weintraub wrote: I find the best way is to just make BAR a releasable subproject. You could zip up its source code or compile bar into some sort of object file that FOO can use (a jarfile for a Java project, or a *.dll or *.so for C or C++ projects). Then, I'd have my build file copy the correct version of bar down from the release repository as part of my build process. That way, you don't have to maintain svn:externals, or be limited by the fact that svn:externals projects have to live in the same repository as the master project. The svn:externals seemed like such a good idea when I first heard of Subversion, but I quickly discovered that it can be very difficult to implement correctly. You just have to treat the sub-components the same as the top level project. That is, make a release branch for them, and tag the final release versions. Then in the top level project release branches, change the externals to reference the appropriate tag for the released components if they weren't there already. -- Les Mikesell lesmikes...@gmail.com
Re: Diff tag against trunk head
On Tue, Nov 23, 2010 at 11:39:00PM +0800, Kevin Connor Arpe wrote: > Hello, > > I am using the latest (stable) version on both Linux and WinSlows. > > For one of my repositories, I created a daily tag of a diary. > > Example: > /project/trunk/important_stuff > /project/tags/2010-11-20/important_stuff > /project/tags/2010-11-21/important_stuff > /project/tags/2010-11-22/important_stuff > etc. > > Each morning I svn copy "important_stuff" (HEAD revision) to the tags > area and commit. > > In theory, this will be used to easily find what changed day-over-day. > Of course all of this is possible poking through svn logs, but I want > to make this easier. > > My question: What is the SVN command to diff a file in a tagged set vs > trunk head? > > Fantasy command: > svn diff -r"tag:2010-11-21" -rHEAD /project/trunk/important_stuff/details.txt > > or... > > svn diff -r"trunk:HEAD" /project/tags/2010-11-21/important_stuff/details.txt > > I tried many different svn diff commands. No luck. I also did some > heavy Google/StackOverflow searching. No luck. > > Is there a simple way to do this? > Right now I am using regular GNU diff, but this requires everyone to > download the tags to their box locally. > > Ideally, this could be done via the trunk or tag URL only. Try this: svn diff URL_OF_TAG URL_OF_TRUNK Stefan
RE: Diff tag against trunk head
> 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: Kevin Connor Arpe [mailto:kevina...@gmail.com] > Sent: 23 November 2010 15:39 > To: users@subversion.apache.org > Subject: Diff tag against trunk head > > Hello, > > I am using the latest (stable) version on both Linux and WinSlows. > > For one of my repositories, I created a daily tag of a diary. > > Example: > /project/trunk/important_stuff > /project/tags/2010-11-20/important_stuff > /project/tags/2010-11-21/important_stuff > /project/tags/2010-11-22/important_stuff > etc. > > Each morning I svn copy "important_stuff" (HEAD revision) to > the tags area and commit. > > In theory, this will be used to easily find what changed day-over-day. > Of course all of this is possible poking through svn logs, > but I want to make this easier. > > My question: What is the SVN command to diff a file in a > tagged set vs trunk head? > > Fantasy command: > svn diff -r"tag:2010-11-21" -rHEAD > /project/trunk/important_stuff/details.txt > > or... > > svn diff -r"trunk:HEAD" > /project/tags/2010-11-21/important_stuff/details.txt > > I tried many different svn diff commands. No luck. I also > did some heavy Google/StackOverflow searching. No luck. > > Is there a simple way to do this? > Right now I am using regular GNU diff, but this requires > everyone to download the tags to their box locally. > > Ideally, this could be done via the trunk or tag URL only. According to the help you can use this format of the svn diff svn diff old-u...@oldrev] new-u...@newrev] So svn diff http://url.to.repo/project/tags/2010-11-21/important_stuff/details.txt http://url.to.repo/project/trunk/important_stuff/details.txt Try it Giulio
Re: Diff tag against trunk head
On Tue, Nov 23, 2010 at 10:39, Kevin Connor Arpe wrote:
> Hello,
>
> I am using the latest (stable) version on both Linux and WinSlows.
>
> For one of my repositories, I created a daily tag of a diary.
>
> Example:
> /project/trunk/important_stuff
> /project/tags/2010-11-20/important_stuff
> /project/tags/2010-11-21/important_stuff
> /project/tags/2010-11-22/important_stuff
> etc.
>
> Each morning I svn copy "important_stuff" (HEAD revision) to the tags
> area and commit.
>
> In theory, this will be used to easily find what changed day-over-day.
> Of course all of this is possible poking through svn logs, but I want
> to make this easier.
>
> My question: What is the SVN command to diff a file in a tagged set vs
> trunk head?
>
> Fantasy command:
> svn diff -r"tag:2010-11-21" -rHEAD /project/trunk/important_stuff/details.txt
>
> or...
>
> svn diff -r"trunk:HEAD" /project/tags/2010-11-21/important_stuff/details.txt
>
> I tried many different svn diff commands. No luck. I also did some
> heavy Google/StackOverflow searching. No luck.
I'm trying to understand how this tagging & diffing between 2 paths is
better/easier than just keeping your single file, and diffing
yesterday's date against HEAD. For example:
svn diff -r {2010-11-22}:HEAD /project/trunk/important_stuff
Use the --summarize switch to just list the paths that have been
modified, if that's all you're after.
If you're just using the file important_stuff to just keep a running
changelog, using svn log with the revision range (yesterday to HEAD)
applied to the trunk URL could also work, with a little extra
scripting & parsing; especially if you can create an XSL stylesheet to
apply to the output of svn log --xml
Re: file externals & URLs
Bastien Semene wrote on Tue, Nov 23, 2010 at 14:43:21 +0100: > Is it still not possible to use file externals pointing on different > repositories ? It is not possible (because the code used to implement in 1.5 and 1.6 them assumes that the target URL belongs to the same repository). I don't recall if it's already fixed in trunk/1.7-to-be.
Note for people using Subversion within PowerShell on Windows
I was just experimenting with a PowerShell v2 session (instead of the
basic Command Prompt) and got the following:
PS C:\_Projects> svn diff -r {2010-11-22}:HEAD
svn: Syntax error in revision argument '-encodedCommand'
If the revision range is enclosed in quotes, it works properly:
PS C:\_Projects> svn diff -r "{2010-11-22}:HEAD"
You can also escape the curly braces with the backtick character.
PS C:\_Projects> svn diff -r `{2010-11-22`}:HEAD
I believe the issue is specifically with the curly braces {}, as those
denote a code block in PowerShell.
Using a revision range of 3000:HEAD does not require that the range be
enclosed in quotes, but I'm going to try to get in the habit of just
quoting the revision range regardless.
Command Prompt works either way - quoted or unquoted, doesn't matter.
I'm on XP, it's probably an issue on newer versions of Windows as
well. Not sure how many folks out there are actually using svn.exe on
Windows in PowerShell, but it's in the list archive now in case anyone
has a similar issue.
Re: Diff tag against trunk head
On 11/23/2010 9:39 AM, Kevin Connor Arpe wrote:
Hello,
I am using the latest (stable) version on both Linux and WinSlows.
For one of my repositories, I created a daily tag of a diary.
Example:
/project/trunk/important_stuff
/project/tags/2010-11-20/important_stuff
/project/tags/2010-11-21/important_stuff
/project/tags/2010-11-22/important_stuff
etc.
Each morning I svn copy "important_stuff" (HEAD revision) to the tags
area and commit.
In theory, this will be used to easily find what changed day-over-day.
Of course all of this is possible poking through svn logs, but I want
to make this easier.
Errr, you do know that you can use a date specifier in curly braces as a
revision don't you? See the 'Revision Dates' section of the
documentation for the recognized formats. You don't really need a tag
just for that purpose - but be sure you understand that if you omit the
timestamp you get the beginning of the day, not the end.
My question: What is the SVN command to diff a file in a tagged set vs
trunk head?
As others have mentioned you can diff 2 urls - and if you have trouble
with the syntax you can add --old= and --new= specifiers. But normally
if you are interested in the code, you'll have a checked out copy of the
trunk already that you can update to get the head revision, then just
'svn diff -r {-MM-DD}'
to diff against the start of a previous day.
--
Les Mikesell
lesmikes...@gmail.com
Re: file externals & URLs
Ok, I just tested. There actually are 2 problems when I first tested the cross repositories file external, the first message I had was : Repository UUID '55a45616-c74e-de11-b3fa-001e4f22e0e6' doesn't match expected UUID '20aedb48-35eb-0310-b593-edfe3b26aac3' So I changed the UUID of my test repository (of course only for test purposes and on a test repository), re-co my wc and I had a new error : 'http://svn.cyanide-studio.com/test/external' is not the same repository as 'http://svn.cyanide-studio.com/admin' It should be noted that I use TortoiseSVN, and maybe the second error is from Tortoise that does some tests. I'm not in the Subversion code, but I think that the problem is not related to URLs, but from UUIDs checks. Anyway I'm happy to know that this is a feature planned for 1.7 ! Le 23/11/2010 17:17, Daniel Shahaf a écrit : Bastien Semene wrote on Tue, Nov 23, 2010 at 14:43:21 +0100: Is it still not possible to use file externals pointing on different repositories ? It is not possible (because the code used to implement in 1.5 and 1.6 them assumes that the target URL belongs to the same repository). I don't recall if it's already fixed in trunk/1.7-to-be. -- Bastien Semene Administrateur Réseau& Système Cyanide Studio - FRANCE
Re: file externals & URLs
On 11/23/2010 10:51 AM, Bastien Semene wrote: Ok, I just tested. There actually are 2 problems when I first tested the cross repositories file external, the first message I had was : Repository UUID '55a45616-c74e-de11-b3fa-001e4f22e0e6' doesn't match expected UUID '20aedb48-35eb-0310-b593-edfe3b26aac3' So I changed the UUID of my test repository (of course only for test purposes and on a test repository), re-co my wc and I had a new error : 'http://svn.cyanide-studio.com/test/external' is not the same repository as 'http://svn.cyanide-studio.com/admin' It should be noted that I use TortoiseSVN, and maybe the second error is from Tortoise that does some tests. I'm not in the Subversion code, but I think that the problem is not related to URLs, but from UUIDs checks. Anyway I'm happy to know that this is a feature planned for 1.7 ! The current version uses the directory structure of your workspace to hold the repository information, so it sort-of makes sense that you can't mix files from different repositories in the same directory. -- Les Mikesell lesmikes...@gmail.com
Re: file externals & URLs
Bastien Semene wrote on Tue, Nov 23, 2010 at 17:51:00 +0100: > Ok, I just tested. > > There actually are 2 problems when I first tested the cross repositories > file external, the first message I had was : > Repository UUID '55a45616-c74e-de11-b3fa-001e4f22e0e6' doesn't match > expected UUID '20aedb48-35eb-0310-b593-edfe3b26aac3' > > So I changed the UUID of my test repository (of course only for test > purposes and on a test repository), Yes. > re-co my wc and I had a new error : > 'http://svn.cyanide-studio.com/test/external' is not the same repository > as 'http://svn.cyanide-studio.com/admin' > > It should be noted that I use TortoiseSVN, and maybe the second error is > from Tortoise that does some tests. > It sounds to me like an input-validation code in the Subversion libraries themselves. > I'm not in the Subversion code, but I think that the problem is not > related to URLs, but from UUIDs checks. I think both of these (URLs and UUIDs) will need to be adjusted. > Anyway I'm happy to know that this is a feature planned for 1.7 ! > It's just another one of those features that the wc rewrite of 1.7 will enable. I don't recall if this is specifically planned for 1.7 or for later --- but the dev@/issues@ archives have a better memory :). Daniel > > Le 23/11/2010 17:17, Daniel Shahaf a écrit : >> Bastien Semene wrote on Tue, Nov 23, 2010 at 14:43:21 +0100: >>> Is it still not possible to use file externals pointing on different >>> repositories ? >> It is not possible (because the code used to implement in 1.5 and 1.6 >> them assumes that the target URL belongs to the same repository). >> >> I don't recall if it's already fixed in trunk/1.7-to-be. > > -- > Bastien Semene > Administrateur Réseau& Système > > Cyanide Studio - FRANCE >
Re: file externals & URLs
Les Mikesell wrote on Tue, Nov 23, 2010 at 11:03:11 -0600: > The current version uses the directory structure of your workspace to > hold the repository information, so it sort-of makes sense that you > can't mix files from different repositories in the same directory. And why would this argument be less valid when subjected to s/files/dirs/ ? There is no reason file externals shouldn't be able to be cross-repository. (They were originally implemented in a way that doesn't allow that, but that's another story.)
Re: file externals & URLs
On 11/23/2010 11:39 AM, Daniel Shahaf wrote: Les Mikesell wrote on Tue, Nov 23, 2010 at 11:03:11 -0600: The current version uses the directory structure of your workspace to hold the repository information, so it sort-of makes sense that you can't mix files from different repositories in the same directory. And why would this argument be less valid when subjected to s/files/dirs/ ? Isn't that obvious? When you create the dir, you get the place to hold the metadata for the corresponding repo - just like any other part of the workspace and equivalent to the reason you have to check out a directory for a workspace, not just a file. There is no reason file externals shouldn't be able to be cross-repository. (They were originally implemented in a way that doesn't allow that, but that's another story.) You could say the same about checking out a single file as your only working copy - or having to have the pristine copy in the metadata at all. When working copies are redesigned to not require the metadata to live under every working copy directory things will be different. But not necessarily better - the current design has some good points, like being able to copy any part of a working copy tree and still have it be a working copy. -- Les Mikesell lesmikes...@gmail.com
Re: URL-only renames adds svn:mergeinfo property
On Fri, Nov 19, 2010 at 12:25 PM, Stefan Sperling wrote: Hi All, The short story, the following behaviors are intentional: A) WC-to-WC [copies | moves]: Destination only gets explicit mergeinfo if the source has it. B) URL-to-[WC | URL] [copies | moves]: Destination gets explicit mergeinfo if the source has it. If the source doesn't have explicit mergeinfo, but inherits it, then that inherited mergeinfo is made explicit on the destination. The slightly longer story... As Stefan already mentioned, in 1.5.0-1.5.4 'A' behaved like 'B'. When we changed the WC-to-WC behavior in 1.5.5, we purposefully didn't change the URL-to-* behavior. But honestly, this was probably as much out of caution as for any other reason, since there are use cases where 'B' helps you even when doing copies within the same branch (see my example that follows). If someone wants to make the argument on the dev list that 'A' should be the default behavior for all copies and moves, I for one am quite willing to listen and probably assist, and maybe do all the coding (which should be pretty minimal), but this isn't on my personal TODO list at the moment. > On Fri, Nov 19, 2010 at 12:38:57PM +0100, Johan Corveleyn wrote: >> I don't see why it matters that it's a "sub-branch". It's still a >> (grand-)child of mybranch, so can perfectly inherit that mergeinfo. >> AFAIU it only needs explicit mergeinfo if it starts to deviate from >> the mybranch root (e.g. if something is (sync-)merged directly to the >> sub-branch). Or am I missing something? > > Hmmm.. I don't see any reason either. Explicit mergeinfo could probably be > created later when the subtree actually becomes a merge target. > I guess the current logic in the code simply doesn't account for the case > where the copy destination is a child of the source? Not sure. The basic problem with not making a copy* source's inherited mergeinfo explicit on the destination is that a bit of merge history can get lost. Here is a simple example of this: Say we have a simple two branch (trunk and branch) repos like this: ---tr...@1---r6---@6-> | text | copy change sync | to merge |D/H/psi| | | V V bra...@2--r7--r9---r10---> WC-to-WCidentical text copy of changes to D/H/psi to D/H/psi-WC D/H/psi-WC and and D/H/psi-URL URL-to-WC copy of D/H/psi to D/H/psi-URL The merge in r7 leaves this mergeinfo on the root of the branch: >svn pl -vR Properties on 'branch': svn:mergeinfo /trunk:2-6 Nothing unusual there. The WC-to-WC copy made in r9 creates no new mergeinfo, but the URL-to-WC copy does create mergeinfo on psi-URL: >svn pl -vR Properties on 'branch': svn:mergeinfo /trunk:2-6 Properties on 'branch\D\H\psi-URL': svn:mergeinfo /trunk/D/H/psi:2-6 This is exactly the behavior Daniel initially reported. Note that r10 makes some changes to psi-URL and psi-WC that conflicts with the changes made in r6. What happens if we attempt to re-merge r6 directly to psi-WC or psi-URL? In the case of psi-URL, nothing happens, the merge is a no-op: >svn merge ^/A/D/H/psi branch\D\H\psi-URL -c6 >svn st > Nor should anything happen, since the merge source, ^/A/D/H/p...@6, is already part of the target's merge history (per its explicit mergeinfo). Now let's try the same merge, but targeting psi-WC. We know from the preceding diagram that psi-WC's merge history should be semantically equivalent to psi-URL's and we *should* get a no-op, but instead... >svn merge ^/trunk/D/H/psi branch\D\H\psi-WC -c6 Conflict discovered in 'branch/D/H/psi-WC'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: p --- Merging r6 into 'branch\D\H\psi-WC': Cbranch\D\H\psi-WC Summary of conflicts: Text conflicts: 1 Why did this happen? Because psi-WC's actual merge history (i.e. its natural history and explicit/implicit mergeinfo) doesn't include '/trunk/D/H/psi:6'. Now you may be thinking, "but doesn't it inherit that history from the root of branch?". Unfortunately it doesn't, it does inherit mergeinfo from branch, but it inherits '/trunk/D/H/psi-WC:6', which is obviously not what we are merging and has the added distinction of not even existing in the repository** This is because mergeinfo inheritance is a simple path-wise calculation: A path without mergeinfo inherits the mergeinfo of its nearest parent with explicit mergeinfo, with all the merge source paths adjusted by the path difference between the path and its parent. Yes, I'd
Re: Note for people using Subversion within PowerShell on Windows
On Nov 23, 2010, at 10:19, Andy Levy wrote:
> I was just experimenting with a PowerShell v2 session (instead of the
> basic Command Prompt) and got the following:
>
> PS C:\_Projects> svn diff -r {2010-11-22}:HEAD
> svn: Syntax error in revision argument '-encodedCommand'
>
> If the revision range is enclosed in quotes, it works properly:
>
> PS C:\_Projects> svn diff -r "{2010-11-22}:HEAD"
>
> You can also escape the curly braces with the backtick character.
>
> PS C:\_Projects> svn diff -r `{2010-11-22`}:HEAD
>
> I believe the issue is specifically with the curly braces {}, as those
> denote a code block in PowerShell.
>
> Using a revision range of 3000:HEAD does not require that the range be
> enclosed in quotes, but I'm going to try to get in the habit of just
> quoting the revision range regardless.
>
> Command Prompt works either way - quoted or unquoted, doesn't matter.
>
> I'm on XP, it's probably an issue on newer versions of Windows as
> well. Not sure how many folks out there are actually using svn.exe on
> Windows in PowerShell, but it's in the list archive now in case anyone
> has a similar issue.
Yes, some shells require you to escape the curly braces.
I was hoping at this point to refer you to the page in the book where this is
explained, but it appears not to be explained there.
http://svnbook.red-bean.com/nightly/en/svn.tour.revs.specifiers.html#svn.tour.revs.dates
Perhaps you could submit feedback to the authors of the book and ask them to
include this information? They have their own mailing list.
Re: Note for people using Subversion within PowerShell on Windows
On Tue, Nov 23, 2010 at 16:08, Ryan Schmidt
wrote:
>
> On Nov 23, 2010, at 10:19, Andy Levy wrote:
>
>> I was just experimenting with a PowerShell v2 session (instead of the
>> basic Command Prompt) and got the following:
>>
>> PS C:\_Projects> svn diff -r {2010-11-22}:HEAD
>> svn: Syntax error in revision argument '-encodedCommand'
>>
>> If the revision range is enclosed in quotes, it works properly:
>>
>> PS C:\_Projects> svn diff -r "{2010-11-22}:HEAD"
>>
>> You can also escape the curly braces with the backtick character.
>>
>> PS C:\_Projects> svn diff -r `{2010-11-22`}:HEAD
>>
>> I believe the issue is specifically with the curly braces {}, as those
>> denote a code block in PowerShell.
>>
>> Using a revision range of 3000:HEAD does not require that the range be
>> enclosed in quotes, but I'm going to try to get in the habit of just
>> quoting the revision range regardless.
>>
>> Command Prompt works either way - quoted or unquoted, doesn't matter.
>>
>> I'm on XP, it's probably an issue on newer versions of Windows as
>> well. Not sure how many folks out there are actually using svn.exe on
>> Windows in PowerShell, but it's in the list archive now in case anyone
>> has a similar issue.
>
> Yes, some shells require you to escape the curly braces.
>
> I was hoping at this point to refer you to the page in the book where this is
> explained, but it appears not to be explained there.
>
> http://svnbook.red-bean.com/nightly/en/svn.tour.revs.specifiers.html#svn.tour.revs.dates
>
> Perhaps you could submit feedback to the authors of the book and ask them to
> include this information? They have their own mailing list.
Issue 107 submitted. http://code.google.com/p/svnbook/issues/detail?id=107
I'd guess most *NIX folks are probably already aware of what
escaping/quoting needs to be done in their shells, but being a
relative newcomer to PowerShell on Windows, this was new to me (though
looking back on it, I should have seen it coming). An extra note in
the book can't hurt.
Re: URL-only renames adds svn:mergeinfo property
On Tue, Nov 23, 2010 at 9:31 PM, Paul Burba wrote: > On Fri, Nov 19, 2010 at 12:25 PM, Stefan Sperling wrote: > > Hi All, > > The short story, the following behaviors are intentional: > > A) WC-to-WC [copies | moves]: Destination only gets explicit mergeinfo > if the source has it. > > B) URL-to-[WC | URL] [copies | moves]: Destination gets explicit > mergeinfo if the source has it. If the source doesn't have explicit > mergeinfo, but inherits it, then that inherited mergeinfo is made > explicit on the destination. > > The slightly longer story... > > As Stefan already mentioned, in 1.5.0-1.5.4 'A' behaved like 'B'. > When we changed the WC-to-WC behavior in 1.5.5, we purposefully didn't > change the URL-to-* behavior. But honestly, this was probably as much > out of caution as for any other reason, since there are use cases > where 'B' helps you even when doing copies within the same branch (see > my example that follows). > > If someone wants to make the argument on the dev list that 'A' should > be the default behavior for all copies and moves, I for one am quite > willing to listen and probably assist, and maybe do all the coding > (which should be pretty minimal), but this isn't on my personal TODO > list at the moment. > >> On Fri, Nov 19, 2010 at 12:38:57PM +0100, Johan Corveleyn wrote: >>> I don't see why it matters that it's a "sub-branch". It's still a >>> (grand-)child of mybranch, so can perfectly inherit that mergeinfo. >>> AFAIU it only needs explicit mergeinfo if it starts to deviate from >>> the mybranch root (e.g. if something is (sync-)merged directly to the >>> sub-branch). Or am I missing something? >> >> Hmmm.. I don't see any reason either. Explicit mergeinfo could probably be >> created later when the subtree actually becomes a merge target. >> I guess the current logic in the code simply doesn't account for the case >> where the copy destination is a child of the source? Not sure. > > The basic problem with not making a copy* source's inherited mergeinfo > explicit on the destination is that a bit of merge history can get > lost. Here is a simple example of this: > > Say we have a simple two branch (trunk and branch) repos like this: > > ---tr...@1---r6---@6-> > | text | > copy change sync > | to merge > | D/H/psi | > | | > V V > bra...@2--r7--r9---r10---> > WC-to-WC identical text > copy of changes to > D/H/psi to D/H/psi-WC > D/H/psi-WC and > and D/H/psi-URL > URL-to-WC > copy of > D/H/psi to > D/H/psi-URL > > The merge in r7 leaves this mergeinfo on the root of the branch: > > >svn pl -vR > Properties on 'branch': > svn:mergeinfo > /trunk:2-6 > > Nothing unusual there. The WC-to-WC copy made in r9 creates no new > mergeinfo, but the URL-to-WC copy does create mergeinfo on psi-URL: > > >svn pl -vR > Properties on 'branch': > svn:mergeinfo > /trunk:2-6 > Properties on 'branch\D\H\psi-URL': > svn:mergeinfo > /trunk/D/H/psi:2-6 > > This is exactly the behavior Daniel initially reported. > > Note that r10 makes some changes to psi-URL and psi-WC that conflicts > with the changes made in r6. What happens if we attempt to re-merge > r6 directly to psi-WC or psi-URL? > > In the case of psi-URL, nothing happens, the merge is a no-op: > > >svn merge ^/A/D/H/psi branch\D\H\psi-URL -c6 > > >svn st > > > > > Nor should anything happen, since the merge source, ^/A/D/H/p...@6, is > already part of the target's merge history (per its explicit > mergeinfo). > > Now let's try the same merge, but targeting psi-WC. We know from the > preceding diagram that psi-WC's merge history should be semantically > equivalent to psi-URL's and we *should* get a no-op, but instead... > > >svn merge ^/trunk/D/H/psi branch\D\H\psi-WC -c6 > Conflict discovered in 'branch/D/H/psi-WC'. > Select: (p) postpone, (df) diff-full, (e) edit, > (mc) mine-conflict, (tc) theirs-conflict, > (s) show all options: p > --- Merging r6 into 'branch\D\H\psi-WC': > C branch\D\H\psi-WC > Summary of conflicts: > Text conflicts: 1 > > Why did this happen? Because psi-WC's actual merge history (i.e. its > natural history and explicit/implicit mergeinfo) doesn't include > '/trunk/D/H/psi:6'. > > Now you may be thinking, "but doesn't it inherit that history from the > root of branch?". Unfortunately it doesn't, it does inherit mergeinfo > from branch, but it inherits '/trunk/D/H/psi-WC:6', which is obviously > not what we are merging and has the added distinction of not even > existing in the repository** > > This is because mergeinfo inheritance is a simpl
svnsync_test.py fails: wrong version of SQLite library
I am attempting to build SVN on a RHEL 5.4 system. There are two versions of SQLite on the system: * The stock system SQLite, version 3.3.6, with library in /usr/lib * A new version of SQLite, version 3.7.3, with library in /usr/sup/lib I configured SVN with the following options: ./configure --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/ (The prefix is because I do not want to clobber the system version of SVN, just make a newer one available.) The build worked without issue; however, 'make check' fails. When I look at the log, I see the following error repeatedly: svnsync: SQLite compiled for 3.7.3, but running with 3.3.6 It looks like svnsync is picking up the wrong version of SQLite, despite being compiled with the correct version. This appears to happen only on svnsync synchronize, but I've not exhaustively read through the logs. I've re-run the tests with LD_LIBRARY_PATH, LD_RUN_PATH, and LIBRARY_PATH set identically to /usr/sup/lib:/usr/local/lib, to no change in behavior. To make sure I wasn't missing something, I rebuilt SVN, configuring it with explicit environment variables: ./configure LDFLAGS=-L/usr/sup/lib CPPFLAGS=-I/usr/sup/include --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/ It fails 'make check' in exactly the same way. When I look at subversion-1.6.13/subversion/svnsync/svnsync, the shell script appears to be clobbering the run-time environment variables. I'm not sure this is pertinent, given that it fails with or without the run-time variables set, and with or without LDFLAGS and CPPFLAGS set. How do I get SVN to pick up the correct version of the library on 'make check' when --with-sqlite (with or without compile-time and run-time environment variables set) doesn't do the right thing? Thanks, MJB
Re: svnsync_test.py fails: wrong version of SQLite library
On Tue, Nov 23, 2010 at 6:16 PM, Michael J. Bauer wrote: > I am attempting to build SVN on a RHEL 5.4 system. There are two versions > of SQLite on the system: > > * The stock system SQLite, version 3.3.6, with library in /usr/lib > * A new version of SQLite, version 3.7.3, with library in /usr/sup/lib > > I configured SVN with the following options: > > ./configure --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/ > > (The prefix is because I do not want to clobber the system version of SVN, > just make a newer one available.) The build worked without issue; however, > 'make check' fails. When I look at the log, I see the following error > repeatedly: > > svnsync: SQLite compiled for 3.7.3, but running with 3.3.6 > > It looks like svnsync is picking up the wrong version of SQLite, despite > being compiled with the correct version. This appears to happen only on > svnsync synchronize, but I've not exhaustively read through the logs. I've > re-run the tests with LD_LIBRARY_PATH, LD_RUN_PATH, and LIBRARY_PATH set > identically to /usr/sup/lib:/usr/local/lib, to no change in behavior. > > To make sure I wasn't missing something, I rebuilt SVN, configuring it with > explicit environment variables: > > ./configure LDFLAGS=-L/usr/sup/lib CPPFLAGS=-I/usr/sup/include > --prefix=/usr/sup/subversion-1.6.13 --with-sqlite=/usr/sup/ > > It fails 'make check' in exactly the same way. > > When I look at subversion-1.6.13/subversion/svnsync/svnsync, the shell > script appears to be clobbering the run-time environment variables. I'm not > sure this is pertinent, given that it fails with or without the run-time > variables set, and with or without LDFLAGS and CPPFLAGS set. > > How do I get SVN to pick up the correct version of the library on 'make > check' when --with-sqlite (with or without compile-time and run-time > environment variables set) doesn't do the right thing? Have you tried building Subversion with the sqlite amalgamation? You can point --with-sqlite at an amalgamation file (as downloaded from sqlite.org), and Subversion will statically include that, removing library conflicts. -Hyrum
Re: URL-only renames adds svn:mergeinfo property
On Wed, Nov 24, 2010 at 6:31 AM, Paul Burba wrote: > On Fri, Nov 19, 2010 at 12:25 PM, Stefan Sperling wrote: > > Hi All, > > The short story, the following behaviors are intentional: > > A) WC-to-WC [copies | moves]: Destination only gets explicit mergeinfo > if the source has it. > > B) URL-to-[WC | URL] [copies | moves]: Destination gets explicit > mergeinfo if the source has it. If the source doesn't have explicit > mergeinfo, but inherits it, then that inherited mergeinfo is made > explicit on the destination. > > The slightly longer story... > > As Stefan already mentioned, in 1.5.0-1.5.4 'A' behaved like 'B'. > When we changed the WC-to-WC behavior in 1.5.5, we purposefully didn't > change the URL-to-* behavior. But honestly, this was probably as much > out of caution as for any other reason, since there are use cases > where 'B' helps you even when doing copies within the same branch (see > my example that follows). > > If someone wants to make the argument on the dev list that 'A' should > be the default behavior for all copies and moves, I for one am quite > willing to listen and probably assist, and maybe do all the coding > (which should be pretty minimal), but this isn't on my personal TODO > list at the moment. > I'm not sure I have a firm argument either way (yet). It is a little strange that the same command would produce different results when done WC-to-WC vs URL-to-*. > > On Fri, Nov 19, 2010 at 12:38:57PM +0100, Johan Corveleyn wrote: > >> I don't see why it matters that it's a "sub-branch". It's still a > >> (grand-)child of mybranch, so can perfectly inherit that mergeinfo. > >> AFAIU it only needs explicit mergeinfo if it starts to deviate from > >> the mybranch root (e.g. if something is (sync-)merged directly to the > >> sub-branch). Or am I missing something? > > > > Hmmm.. I don't see any reason either. Explicit mergeinfo could probably > be > > created later when the subtree actually becomes a merge target. > > I guess the current logic in the code simply doesn't account for the case > > where the copy destination is a child of the source? Not sure. > Now let's try the same merge, but targeting psi-WC. We know from the > preceding diagram that psi-WC's merge history should be semantically > equivalent to psi-URL's and we *should* get a no-op, but instead... > > >svn merge ^/trunk/D/H/psi branch\D\H\psi-WC -c6 > Conflict discovered in 'branch/D/H/psi-WC'. > Select: (p) postpone, (df) diff-full, (e) edit, > (mc) mine-conflict, (tc) theirs-conflict, > (s) show all options: p > --- Merging r6 into 'branch\D\H\psi-WC': > Cbranch\D\H\psi-WC > Summary of conflicts: >Text conflicts: 1 > But merging the parent directories is a no-op, because the explicit merge info on /branch stops r6 from being merged again. > Why did this happen? Because psi-WC's actual merge history (i.e. its > natural history and explicit/implicit mergeinfo) doesn't include > '/trunk/D/H/psi:6'. > > Now you may be thinking, "but doesn't it inherit that history from the > root of branch?". Unfortunately it doesn't, it does inherit mergeinfo > from branch, but it inherits '/trunk/D/H/psi-WC:6', which is obviously > not what we are merging and has the added distinction of not even > existing in the repository** > > This is because mergeinfo inheritance is a simple path-wise > calculation: A path without mergeinfo inherits the mergeinfo of its > nearest parent with explicit mergeinfo, with all the merge source > paths adjusted by the path difference between the path and its parent. > > Yes, I'd love to come up with a more concise way to explain that! > The mergeinfo (from the parent) is /trunk:6, which means that the changes made to /trunk in r6 have already been merged into a parent. I guess it's naive for SVN to work out that I'm trying to merge a change to a sub-tree of /trunk to a sub-tree of /branches, when the same revision has been merged into a parent. I guess it's because SVN only looks at the merge target itself when determine the eligible revisions, rather than walking the tree until it hits a node with explicit mergeinfo. > Anyhow, that is where not recording the source's inherited mergeinfo > on the copy destination can bite us. Is is a big problem? Not sure, > but the workaround to avoid it, using WC-to-WC copies, doesn't seem > that draconian. If you agree or not, I'm more than happy to kick > around improvements on the dev list. > Agreed. The case that I had came about due to a case-only rename, and because we run windows, we did it via a URL (rather than an intermediate commit). We'll know for next time. :-) > Thanks, > > Paul > > * I talk about copies here, but the same issues apply to moves. > > ** In 1.7 I made improvements so that such bogus inherited mergeinfo > doesn't get recorded, see > http://subversion.tigris.org/issues/show_bug.cgi?id=3669, but in > 1.5-1.6 we have that added insult. >
Re: svnsync_test.py fails: wrong version of SQLite library
On Tue, Nov 23, 2010 at 7:16 PM, Michael J. Bauer wrote: > I am attempting to build SVN on a RHEL 5.4 system. There are two versions > of SQLite on the system: Use the SRPM or the RPM from RPMforge. I've had some involvement with that: previous contributors included the squlite-amalgmation tarball, which is used at compile time to provide statically loaded libraries and brings it successfully into RHEL 5.x compatibilyy. RHEL 5's version is perilously out of date for both security and performance reasons: I strongly recommend the RPMforge subversion-1.6.13 toolsuite. It's one issue is that RPMforge doesn't publish i386 packages in the same repository as x86_64 packages, and RHEL does, so you have to play yum configuration games to avoid loading the subversion-1.4.2-1.i386.rpm from RHEL, and the subversion-1.6.13-[release].x86_64.rpm from RPMforge and causing chaos.
Re: svnsync_test.py fails: wrong version of SQLite library
Michael J. Bauer wrote on Tue, Nov 23, 2010 at 19:16:32 -0500: > It looks like svnsync is picking up the wrong version of SQLite, despite > being compiled with the correct version. This appears to happen only on > svnsync synchronize, but I've not exhaustively read through the logs. I'd be surprised if only svnsync (and MUCH more surprised if only 'svnsync sync') complain about wrong libraries. The sqlite library should be loaded by other cmdline utilities too...
