RE: Strange behavior on directory delete/commit
You could also delete the directory directly in the repository using svn delete url -m message. This way you would avoid the problem of committing partial changes of your working copy. .. which is just another workaround.
RE: Strange behavior on directory delete/commit
I think SVN is behaving correctly. When you do svn commit foo you're telling Subversion to commit changes made in foo. There are no changes in foo because it's been deleted. The changes, instead, are in its parent directory, the one from where you issued your commands. That's why svn commi works, it assumes . as the path. I disagree. Providing a PATH argument should tell svn that one wants to commit the changes to foo. In this case it would be that foo was deleted. Since I want only the changes to foo to be versioned, it would not make sense to include all other changes within the parent directory. I think svn commit foo would work fine, provided you do not rmdir foo first; that was your error. I also have a feeling Subversion 1.7's new working copy arrangement will fix or at least change this behavior. So there's still a light at the far end of the tunnel! :o) From what I've read just now 1.7.X's WC arrangement will become alike hg's way. I understand well that the current svn infrastructure is not suited for this usecase. Would patching svn 1.6.X to fix the behaviour be feasible?
Re: Strange behavior on directory delete/commit
On Aug 3, 2011, at 03:04, Dominik Psenner wrote: I think svn commit foo would work fine, provided you do not rmdir foo first; that was your error. I also have a feeling Subversion 1.7's new working copy arrangement will fix or at least change this behavior. So there's still a light at the far end of the tunnel! :o) From what I've read just now 1.7.X's WC arrangement will become alike hg's way. I understand well that the current svn infrastructure is not suited for this usecase. Would patching svn 1.6.X to fix the behaviour be feasible? I doubt it. Or rather, the behavior is not broken. The user is broken. As I said: svn commit foo should have worked fine if you had not run rmdir foo beforehand. Don't run rmdir foo. Just run svn rm foo followed by svn commit foo and everything should work.
RE: Strange behavior on directory delete/commit
I doubt it. Or rather, the behavior is not broken. The user is broken. As I said: svn commit foo should have worked fine if you had not run rmdir foo beforehand. Don't run rmdir foo. Just run svn rm foo followed by svn commit foo and everything should work. True - it's nothing totally new to me. I just doubt the lusers who are going to use the frontend I'm writing for them understand the difference. :-)
Re: Strange behavior on directory delete/commit
On Aug 3, 2011, at 03:17, Dominik Psenner wrote: I doubt it. Or rather, the behavior is not broken. The user is broken. As I said: svn commit foo should have worked fine if you had not run rmdir foo beforehand. Don't run rmdir foo. Just run svn rm foo followed by svn commit foo and everything should work. True - it's nothing totally new to me. I just doubt the lusers who are going to use the frontend I'm writing for them understand the difference. :-) Then you must explain it to them. :) To move or delete items in a working copy, you must use svn commands. You must not use OS commands. That's just how it is.
RE: Strange behavior on directory delete/commit
Then you must explain it to them. :) To move or delete items in a working copy, you must use svn commands. You must not use OS commands. That's just how it is. This is going to be a long journey. *jokingly* Thanks for the insights and incredibly fast answers! It's awesome that you're working on the .svn meta-data folders problem. If you manage to get it settled, I believe 1.7.X is going to be great!
Re: svn-crash-log20110801153746, svn-crash-log20110802202337
On Tue, Aug 02, 2011 at 08:38:47PM +0400, Alexander Gushchin wrote: Process info: Cmd line: svn merge -r 12265:13078 svn://ekb.developonbox.ru:3690/DOB2PE/tr Version: 1.6.12 (SlikSvn/1.6.12) WIN32, compiled Jun 22 2010, 20:45:23 Version 1.6.12 of SlikSvn has known crash problems. Please update.
Re: Strange behavior on directory delete/commit
On Wed, Aug 03, 2011 at 10:25:07AM +0200, Dominik Psenner wrote: Then you must explain it to them. :) To move or delete items in a working copy, you must use svn commands. You must not use OS commands. That's just how it is. This is going to be a long journey. *jokingly* Thanks for the insights and incredibly fast answers! It's awesome that you're working on the .svn meta-data folders problem. If you manage to get it settled, I believe 1.7.X is going to be great! I'm not sure you understand the kinds problems the new working copy format is settling. You must still use svn commands instead of OS commands in 1.7. That won't change. I don't think it will ever change. The reason is that Subversion tracks operations explicitly, rather than implicitly. In other words, Subversion needs to modify meta-data in the .svn directory if you change something. If you run an OS-level command the actual disk state and the meta-data get out of sync. Subversion is not like git which goes Woaaahh... I just woke up and now... what??? What did the user DO??? Well, whatever, I'm just gonna take a wild guess to deal with this and go back to bed... Both approaches have advantages and disadvantages.
RE: Strange behavior on directory delete/commit
I'm not sure you understand the kinds problems the new working copy format is settling. For me it settles the major problem of multiple .svn folders in a checkout. You must still use svn commands instead of OS commands in 1.7. That won't change. I don't think it will ever change. The reason is that Subversion tracks operations explicitly, rather than implicitly. In other words, Subversion needs to modify meta-data in the .svn directory if you change something. If you run an OS-level command the actual disk state and the meta-data get out of sync. *sarcastic* The user does not care what levers subversion needs to pull to show him what parts of a file were modified. */sarcastic* Subversion is not like git which goes Woaaahh... I just woke up and now... what??? What did the user DO??? Well, whatever, I'm just gonna take a wild guess to deal with this and go back to bed... Please correct me if I'm wrong: Subversion is still an observer and whatever a user does, he must tell Subversion what he did in cases where subversion can't understand it by itself (i.e. file/folder rename/move that preserve history across the revisions). Every VCS I know works like this. Maybe one invents a VCS filesystem that can hook into the filesystem operations, but that's something that will be written on other papers. ;-) Back to topic: The current working copy layout is unable to handle the usecase I described since it needs the missing meta-data that was stored within the deleted folder itself. Thus Subversion 1.7 would need a special logic to handle these cases. One could discuss whether this should be fixed so that 1.7 behaves on folder deletes just alike file deletes. I leave that decision up to the devs since I'm unable to estimate the costs. The new working copy layout does not have the meta-data within subfolders and thus is able to commit just that change. HOORAY! This issue *can* be solved with WC-NG without special logics! --quote Ryan Schmidt-- I also have a feeling Subversion 1.7's new working copy arrangement will fix or at least change this behavior. --eof quote Ryan Schmidt-- Greetings, D.
RE: Strange behavior on directory delete/commit
[snip] Subversion is still an observer and whatever a user does, he must tell Subversion what he did in cases where subversion can't understand it by itself (i.e. file/folder rename/move that preserve history across the revisions). Every VCS I know works like this. Maybe one invents a VCS Sort of. Mercurial is perfectly happy if you tell it afterwards (before a commit of course) that you renamed that file and deleted the other one. This behavior comes in handy, if you have to rename some files in the IDE, because only the IDE knows what (and in which file) has to be renamed... Best regards Andreas -- Andreas Tscharner andreas.tschar...@metromec.ch -- Intruder on level one. All Aliens please proceed to level one. -- Call in Alien: Resurrection CT-Dienstleistungen neu bei Wenzel Metromec === Haben Sie einen Prototyp ohne Zeichnung oder Konstruktionsmodell? Suchen Sie in Ihren Bauteilen Materialschäden, Risse und Poren? Dann sind unsere neuen Dienstleistungen im Bereich der Computertomographie die perfekte Lösung für Ihre Anforderungen! Testen Sie uns und unsere neue WENZEL exaCT Anlage. Zögern Sie nicht und nehmen Sie noch heute mit uns Kontakt auf. mailto:c...@metromec.ch?subject=CT-Dienstleistungen
RE: Strange behavior on directory delete/commit
[snip] Subversion is still an observer and whatever a user does, he must tell Subversion what he did in cases where subversion can't understand it by itself (i.e. file/folder rename/move that preserve history across the revisions). Every VCS I know works like this. Maybe one invents a VCS Sort of. Mercurial is perfectly happy if you tell it afterwards (before a commit of course) that you renamed that file and deleted the other one. This behavior comes in handy, if you have to rename some files in the IDE, because only the IDE knows what (and in which file) has to be renamed... It smells differently, but is basically the same. :-) But now I understand what Stefan Sperling wanted to point out.
Re: Strange behavior on directory delete/commit
On Wed, Aug 03, 2011 at 11:27:48AM +0200, Dominik Psenner wrote: You must still use svn commands instead of OS commands in 1.7. That won't change. I don't think it will ever change. The reason is that Subversion tracks operations explicitly, rather than implicitly. In other words, Subversion needs to modify meta-data in the .svn directory if you change something. If you run an OS-level command the actual disk state and the meta-data get out of sync. *sarcastic* The user does not care what levers subversion needs to pull to show him what parts of a file were modified. */sarcastic* File modifications are detected automatically. This is easy because files have timestamps, and because Subversion has a pristine copy of each file in the .svn directory. And there is no ambiguity -- a file is either modified or it isn't. But for tree changes, Subversion provides commands, and users must use the commands to operate on the tree. The current working copy layout is unable to handle the usecase I described since it needs the missing meta-data that was stored within the deleted folder itself. Yes, this is one use case that 1.7 fixes. You can now replace directories without having to commit the deletion of the replaced directory separately from the addition of the replacing directory. E.g. you can delete a directory and move a different one on top: $ svn rm epsilon D epsilon D epsilon/zeta $ svn mv gamma epsilon A epsilon D gamma D gamma/delta $ svn status D gamma D gamma/delta R +epsilon D epsilon/zeta and commit the result in a single revision: r3 | stsp | 2011-08-03 12:27:38 +0200 (Wed, 03 Aug 2011) | 1 line Changed paths: R /trunk/epsilon (from /trunk/gamma:2) D /trunk/gamma 1.6 used to error out in the second step: svn: Cannot copy to 'epsilon' as it is scheduled for deletion
SVN Export
Hello All, I wanted to export the file from a location in branch to my local machine. However, I am getting the following error message. M:\Releases\20110805svn export -r 186 http://unity-prod.csfb.net:8081/essbase/branches/test_branch/Essbase/EPM /Batch/EPMPBT1/app/psfsprod/dct/rules/dctscenario.rul M:\Releases\20110805\EPMPBT1\app\psfsprod\dct\rules\ Source :- http://unity-prod.csfb.net:8081/essbase/branches/test_branch/Essbase/EPM /Batch/EPMPBT1/app/psfsprod/dct/rules/dctscenario.rul http://unity-prod.csfb.net:8081/essbase/branches/test_branch/Essbase/EP M/Batch/EPMPBT1/app/psfsprod/dct/rules/dctscenario.rul Destination :- M:\Releases\20110805\EPMPBT1\app\psfsprod\dct\rules\ Error message:- svn: Can't open 'M:\Releases\20110805\EPMPBT1\app\psfsprod\dct\tempfile.tmp': Th e system cannot find the path specified. Kindly help me with the below error. Thanks, Ashish Bhat CREDIT SUISSE AG === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===
Proactive Question on setting up SVN repo
We have a Blade Center downstairs with a NAS mounted to it for additional
storage. I'm in the process of setting up a SVN server for folks in our
company umbrella to use. My boss wants a folder on the NAS to be used as the
repo storage location, due to the extra space and redundancy we have on it.
Thus...
I have SVN 1.6.11 installed on a fresh install of CentOS 6 (on the Blade
Center). I have mounted the NAS running NFS to be used as the repository
storage location on /var/svn/. When I run svnadmin create
/var/svn/new-repo, it hangs for a few seconds, and then says (twice)
svnadmin: database is locked. However, when I go into new-repo and run
ls -la, I see the subversion skeleton files.
After lots of googling and brainstorming, I finally edited /etc/fstab and
added the nolock option to the NFS partition when it gets mounted (and
then these errors went away).
I do understand folks' hesitation to use a network file system as the
location for repositories. I have hidden the folder on the NAS, and have set
permissions appropriately so only the authorized people (who know that
messing with SVN repo files manually can royally screw everything up). All
of this aside
Do you forsee problems with the NAS being mounted with the nolock option?
In /etc/fstab, the line looks like this:
{private-ip}:/volume1/svn /var/svn nfs nolock 0 0
My guess is, if you get two people trying to do commits at the same time
(which is unlikely right now, but as we grow, could become more possible),
things could get corrupted. So, how worried should I be about this? If it's
going to cause royal pains in the future, how would you suggest I fix the
database is locked error message when the nolock isn't enabled on the
mount?
--
- David White -
Smooth Stone Services
Computer Technical Support, IT Services, Web Hosting Solutions
http://www.smoothstoneservices.com
Re: Proactive Question on setting up SVN repo
That message probably comes from SQLite.
SQLite uses the same locks FSFS uses internally.
FSFS depends on locks to ensure consistency with multiple writers.
FSFS does not guarantee correctness without locks. (Concretely:
without locks, if you run 'svnadmin pack' twice concurrently, you can
lose a shard of data. If you run two commits concurrently, you can
pretty easily have both of them succeed and claim to be r42 (and then
one of your developers needs to rm -rf a working copy).)
Does that spell Don't do that?
David White wrote on Wed, Aug 03, 2011 at 07:56:15 -0400:
We have a Blade Center downstairs with a NAS mounted to it for additional
storage. I'm in the process of setting up a SVN server for folks in our
company umbrella to use. My boss wants a folder on the NAS to be used as the
repo storage location, due to the extra space and redundancy we have on it.
Thus...
I have SVN 1.6.11 installed on a fresh install of CentOS 6 (on the Blade
Center). I have mounted the NAS running NFS to be used as the repository
storage location on /var/svn/. When I run svnadmin create
/var/svn/new-repo, it hangs for a few seconds, and then says (twice)
svnadmin: database is locked. However, when I go into new-repo and run
ls -la, I see the subversion skeleton files.
After lots of googling and brainstorming, I finally edited /etc/fstab and
added the nolock option to the NFS partition when it gets mounted (and
then these errors went away).
I do understand folks' hesitation to use a network file system as the
location for repositories. I have hidden the folder on the NAS, and have set
permissions appropriately so only the authorized people (who know that
messing with SVN repo files manually can royally screw everything up). All
of this aside
Do you forsee problems with the NAS being mounted with the nolock option?
In /etc/fstab, the line looks like this:
{private-ip}:/volume1/svn /var/svn nfs nolock 0 0
My guess is, if you get two people trying to do commits at the same time
(which is unlikely right now, but as we grow, could become more possible),
things could get corrupted. So, how worried should I be about this? If it's
going to cause royal pains in the future, how would you suggest I fix the
database is locked error message when the nolock isn't enabled on the
mount?
--
- David White -
Smooth Stone Services
Computer Technical Support, IT Services, Web Hosting Solutions
http://www.smoothstoneservices.com
RE: Proactive Question on setting up SVN repo
Can you install SVN on the NAS? I'm running a QNAP NAS at home with subversion
on it.
Just an idea.
From: David White [mailto:dwr...@gmail.com]
Sent: Wednesday, August 03, 2011 7:56 AM
To: users@subversion.apache.org
Subject: Proactive Question on setting up SVN repo
We have a Blade Center downstairs with a NAS mounted to it for additional
storage. I'm in the process of setting up a SVN server for folks in our company
umbrella to use. My boss wants a folder on the NAS to be used as the repo
storage location, due to the extra space and redundancy we have on it. Thus...
I have SVN 1.6.11 installed on a fresh install of CentOS 6 (on the Blade
Center). I have mounted the NAS running NFS to be used as the repository
storage location on /var/svn/. When I run svnadmin create /var/svn/new-repo,
it hangs for a few seconds, and then says (twice) svnadmin: database is
locked. However, when I go into new-repo and run ls -la, I see the
subversion skeleton files.
After lots of googling and brainstorming, I finally edited /etc/fstab and added
the nolock option to the NFS partition when it gets mounted (and then these
errors went away).
I do understand folks' hesitation to use a network file system as the location
for repositories. I have hidden the folder on the NAS, and have set permissions
appropriately so only the authorized people (who know that messing with SVN
repo files manually can royally screw everything up). All of this aside
Do you forsee problems with the NAS being mounted with the nolock option? In
/etc/fstab, the line looks like this:
{private-ip}:/volume1/svn /var/svn nfs nolock 0 0
My guess is, if you get two people trying to do commits at the same time (which
is unlikely right now, but as we grow, could become more possible), things
could get corrupted. So, how worried should I be about this? If it's going to
cause royal pains in the future, how would you suggest I fix the database is
locked error message when the nolock isn't enabled on the mount?
--
- David White -
Smooth Stone Services
Computer Technical Support, IT Services, Web Hosting Solutions
http://www.smoothstoneservices.com
Re: cannot create directory in /db/transactions/
just double checked /etc/selinux/config and found SELinux is disabled on my CentOS 5 by default. It seems the system does not has Apparmor. Reboot the system, and the problem went away. Now I can create directory in ../db/transaction. Not sure what's the reason behind the scene. -- All the best, Michael Chen
svnlook changed - howto see all deleted files in pre-/post-commit hooks
Dear SVN-experts, I'd like to ask if there is a way to see which particular files have been deleted when a directory deletion has been commited. Example: I add to a repository BAR/Apps the folder Jacobi. With svnlook changed $REPOS in the post-commit hook I get the output: A BAR/Apps/Jacobi/ A BAR/Apps/Jacobi/LICENSE A BAR/Apps/Jacobi/Makefile A BAR/Apps/Jacobi/Readme A BAR/Apps/Jacobi/bin/ A BAR/Apps/Jacobi/src/ A BAR/Apps/Jacobi/src/jacobi.c On deleting the folder Jacobi from the repository and running $SVNLOOK changed $REPOS --transaction $TXN I'm getting only. D BAR/Apps/Jacobi/ Since I'm parsing a Readme file to update a TRAC front-end, I would very much need to see the individual files that were deleted in the Jacobi folder, including the Readme. Is there a way of getting this information? Thanks a lot, Jan.
svnlook changed - howto see all deleted files in pre-/post-commit hooks
Dear SVN-experts, I'd like to ask if there is a way to see which particular files have been deleted when a directory deletion has been commited. Example: I add to a repository BAR/Apps the folder Jacobi. With svnlook changed $REPOS in the post-commit hook I get the output: A BAR/Apps/Jacobi/ A BAR/Apps/Jacobi/LICENSE A BAR/Apps/Jacobi/Makefile A BAR/Apps/Jacobi/Readme A BAR/Apps/Jacobi/bin/ A BAR/Apps/Jacobi/src/ A BAR/Apps/Jacobi/src/jacobi.c On deleting the folder Jacobi from the repository and running $SVNLOOK changed $REPOS --transaction $TXN I'm getting only. D BAR/Apps/Jacobi/ Since I'm parsing a Readme file to update a TRAC front-end, I would very much need to see the individual files that were deleted in the Jacobi folder, including the Readme. Is there a way of getting this information? Thanks a lot, Jan.
svn docx missing mime type workaround?
IE7/8 do not like to correctly open MS office .docx files served directly from a svn repo with the default svn mime type. They will only allow you to save them since it determines they are zip files. The obvious solution is to just add the correct svn:mime-type, which works fine, although it requires changes on every client if you want to use auto props. I was also able to do the following change on my apache 2.2 server to override the default Content-Type header value. (You must have previously loaded the apache headers module for this to work...) IfModule headers_module # Fix docx handling for IE7 SetEnvIf Request_URI \.docx$ docx_file Header set Content-Type application/vnd.openxmlformats-officedocument.wordprocessingml.document env=docx_file /IfModule docx files now are identified as word documents and the user can open them from IE7/8 without having to save an intermediate copy first. The biggest downside I can see is that this will always override the Content-Type for .docx files, including any values set by the user using the svn:mime-type property. Anyone see any obvious other problems? Kevin R.
Re: svn docx missing mime type workaround?
I'm not sure how that interacts with the internal URL svn uses --- e.g., those /repos/!svn/* URLs that sometime appear in error messages. kmra...@rockwellcollins.com wrote on Wed, Aug 03, 2011 at 11:14:18 -0500: IE7/8 do not like to correctly open MS office .docx files served directly from a svn repo with the default svn mime type. They will only allow you to save them since it determines they are zip files. The obvious solution is to just add the correct svn:mime-type, which works fine, although it requires changes on every client if you want to use auto props. I was also able to do the following change on my apache 2.2 server to override the default Content-Type header value. (You must have previously loaded the apache headers module for this to work...) IfModule headers_module # Fix docx handling for IE7 SetEnvIf Request_URI \.docx$ docx_file Header set Content-Type application/vnd.openxmlformats-officedocument.wordprocessingml.document env=docx_file /IfModule docx files now are identified as word documents and the user can open them from IE7/8 without having to save an intermediate copy first. The biggest downside I can see is that this will always override the Content-Type for .docx files, including any values set by the user using the svn:mime-type property. Anyone see any obvious other problems? Kevin R.
SVN errors with junction points
Our SVN checkout is too big to fit on my small SSD harddisk, so I have spread it over two harddisks using Windows 7 junction points. However, this gives me weird SVN errors. These folders are my situation: E:\SVN\BigFolder D:\SVN\SmallFolder D:\SVN\BigFolder junction point towards E:\SVN\BigFolder I want to use the SVN entirely through d:\SVN and just pretent everything is there. Windows Explorer does that exactly, but SVN gives me weird errors: -When I try to update D:\SVN\BigFolder, I get this error: D:\SVN\BigFolder has no ancestry information. -When I try to commit a file that is in D:\SVN\Bigfolder, I get this error: Commit failed (details follow): Entry for D:\SVN\BigFolder has no URL. Try a CleanUp. If that doesn't work you need to do a fresh chackout. I found a topic on the newsgroups that said SVN doesn't support creating and removing junction points, but I am just trying to submit a file inside an already existing junction point. Interestingly, I have several other folders like BigFolder, and some work, while some others don't. Also, which works and which doesn't seems to randomly change sometimes. So, what is going wrong here and how can I fix it? Thanks in advance! With kind regards, Joost
TortoiseSVN crashes
Hi, After updating to TortoiseSVN 1.6.99, Build 21709 - 32 Bit , 2011/07/22 16:21:33, a crash follows each operations with repository (some operations works fine, some fails, but crash report after each). Crash message is about memory 0x0200ad24 reading. System is Windows XP professional. When I try to update one of repository folders, I get the message, witch screenshot is in the attachment. What can I do with this? Thank you. attachment: crash.png
Re: Subversion transactions within post-commit
On 4 August 2011 01:59, David Weintraub qazw...@gmail.com wrote: ... SNIP ... I have what I call my Kitchen Sink pre-commit trigger that does all sorts of stuff. One of the tasks it can do is ban files based upon their name (either regular expression or Ant glob). If a user adds a file with a forbidden name, the commit is rejected and the user is informed of the offending file. The user has to remove the file from their commit and try again. Thanks guys. I'm just stupid. I've been going on and on about what we want to do, but I haven't even stated the obvious: * It's just about removing stale files from being tracked by Subversion, _without_ committer intervention. Basically, our developers (did|can do) this thing manually (remove an older version of a binary they are committing). I wanted to automate this. That's all! So, after the discussion here, it's evident I'm doing this all wrong. I've now just reverted our stuff to the last best working state, and I'll be working on something based on: pre-commit (as much filtering as possible during this stage) post-commit (update the checkout) rsync (mirror the checkout for publishing; do not reflect stale files) cron (to svn rm; svn ci the stale files) -- GPG/PGP ID: 19BAA7AD
Re: Subversion transactions within post-commit
On Wed, Aug 3, 2011 at 2:31 PM, Ray Rashif sc...@archaudio.org wrote: On 4 August 2011 01:59, David Weintraub qazw...@gmail.com wrote: Thanks guys. I'm just stupid. I've been going on and on about what we want to do, but I haven't even stated the obvious: * It's just about removing stale files from being tracked by Subversion, _without_ committer intervention. Basically, our developers (did|can do) this thing manually (remove an older version of a binary they are committing). I wanted to automate this. That's all! Is this binary file a file that's built out of your source code? If it is, it shouldn't be in your repository at all. Instead, it should be built when the deployment is needed. That's what Jenkins and Hudson can do for you. When the code is checked in, they'll do the build, recreate the binary, and do deployment automatically. Your developers can go to the Jenkins/Hudson webpage and download the deployment including the built files. Since Jenkins/Hudson can store multiple builds, there's no need for any built objects to be stored in your source code. Jenkins and Hudson are simple to setup, easy to use, yet very powerful tools. Take a look at http://jenkins-ci.org. (Jenkins and Hudson are a forks off the original Sun project called Hudson. Oracle bought Sun, and the main developer of Hudson left and took the code with him as well as most of the other developers. Oracle owns the Hudson name, so the developers renamed the project Jenkins. Now, both projects claim they're the original and the other is a mere fork. As of now, most of the activity is on Jenkins which is what I use.) -- David Weintraub qazw...@gmail.com
Re: 1.7 check-swig-py failure
Thanks for your consideration of this issue. Unfortunately I have to
apologize, this is not an issue with r878293.
The issue arises when you are building subversion against apr/apu that has
already
been installed in a special location, was built with the internal expat,
and there is another incompatible apr/apu in the system location that
contains libexpat. Then many libraries will load the undesired (system)
apr/apu which leads to the test
failure.
The problem starts when the subversion make tries to configure serf.
It uses the results of apu-1-config --link-libtool --libs as a portion of
SERF_LIBS. Because
the apu is already installed this can include something like
/specialpath/lib/libaprutil-1.la -lexpat.
When libtool links libserf the -lexpat option can turn into a dependency_lib
entry corresponding to the
system libexpat.la. This dependency then is inherited by libsvn_ra_serf,
and then by
libsvn_ra. In resolving these dependencies when linking downstream libs the
RPATH of the downstream libs
may contain a reference to the system location of libexpat (which contains
the downlevel system apr/apu).
As a result of the order of the generated RPATH entries libsvn_ra_serf
correctly loads the special apr/apu,
but libsvan_ra does not. Further downstream libraries also incorrectly load
the system apr/apu and
cause the test failure.
This can be avoided if serf is built outside of the subversion make by
configuring serf with
LDFLAGS=-L/specialpath/lib. Then the dependency_lib entry of libserf for
expat will refer to the
specially built libexpat.la instead of the system one. It can also be
avoided by building against the
special apr/apu build directories instead of the installed version. In this
case apu-1-config will
return something like
/apr-util-buildpath/libaprtuil-1.la/apr-util-buildpath/xml/expat/
libexpat.la for use
in SERF_LIBS, and the dependancy_lib entry in libserf-0.la will not refer to
the system libexpat.la,
which can prevent the path of the system libexpat from being added to RPATH
of the downstream libs.
My test system based on a RHEL 5 derivative.
It would be nice if it was easier to build subversion on this system,
but I am not sure this is a subversion problem, it seems more like an issue
with apr-util and serf.
But it certainly made it hard for me to build subversion!
On Mon, Aug 1, 2011 at 6:06 PM, Daniel Shahaf d...@daniel.shahaf.namewrote:
I can't keep track of the chain of reversions there. Can you post this
to dev@ please with a description of the regression --- i.e., how
specifically the results you get from invocation X in 1.6.x differ from
the results of X in 1.7.0-beta2, and where do you think
configure.ac/Makefile.in are wrong (it sounds like you have that
pinpointed).
Thanks.
tsteven four wrote on Mon, Aug 01, 2011 at 08:21:52 -0600:
I believe I have chased this down to r878293, a change to apr.m4 and
aprutil.m4. SVN_APR_LIBS and SVN_APRUTIL_LIBS used to be set based on
--link-libtool, now they are set on --link-ld. But when building the
swig-py target the libraries are linked with libtool and thus according
to
the apr-1-config/apu-1-config help the --link-libtool option is correct.
When I look at my 1.6.17 build the subversion/bindings/swig/python/.libs
correctly include the local apr and aprutil, but in 1.7.0-beta2 they are
picking up the system versions.
On Fri, Jul 29, 2011 at 12:21 PM, Daniel Shahaf d...@daniel.shahaf.name
wrote:
Stefan Sperling wrote on Fri, Jul 29, 2011 at 18:32:40 +0200:
On Fri, Jul 29, 2011 at 09:12:57AM -0600, tsteven four wrote:
ldd and readelf shown above. Is there some method to get python
use
the
RPATH in libsvn_ra_serf as ldd does so the correct libapr is found,
or
is
the python check overriding RPATH with
some method like LD_LIBRARY_PATH?
Yes, you need to set LD_LIBRARY_PATH.
You also need to make sure that none of the libraries that get loaded
indirectly load the incompatible system libraries... it can get quite
hairy.
I'm not sure I recommend your build --- it rebuilds its own python and
bzip2.
Personally I'm trying to see if just installing the system svn to an
out-of-${*PATH} location works. (ie, I used this technique on one box
and now I'm trying to see if I can survive that way)
See this for various workarounds that I use in my build:
https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/unix-build/
assertion failed (svn_dirent_is_absolute(local_abspath)) in SVN 1.7 beta
Using TortoiseSVN 1.7.0 beta 2 on WinXP SP3: TortoiseSVN 1.6.99, Build 21735 - 32 Bit , 2011/07/28 20:35:52 Subversion 1.7.0, -dev apr 1.4.5 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.0d 8 Feb 2011 zlib 1.2.5) I was in the middle of merging a few revisions from trunk to a branch (using the Merge a range of revisions option), got conflicts on two files and resolved them using TortoiseMerge, then clicking on the Resolved button. I then got a conflict on a third file, resolved that in TortoiseMerge, but after I exited TortoiseMerge and clicked on the Resolved button, I got the following assertion failure: --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list (users@subversion.apache.org) 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: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7-beta2\ext\subversion\subversion\libsvn_wc\wc_db.c' line 1481: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK --- -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: SVN errors with junction points
On Wed, Aug 03, 2011 at 06:18:11PM +0200, Joost van Dongen wrote: Our SVN checkout is too big to fit on my small SSD harddisk, so I have spread it over two harddisks using Windows 7 junction points. Sorry, Subversion doesn't support NTFS junctions. See http://subversion.tigris.org/issues/show_bug.cgi?id=3570
