Re: SVN errors with junction points
Some additional information: I just discovered that the ancestry information error is only given when a file has actually been changed or added. So if there are no updates for a folder on the SVN, then pressing update goes fine. If there is something to get, then I get the ancestry error. @Mark: The E disc contains lots of other data, and BigFolder is not the only folder I did this to. There are around 10 more folders like BigFolder. So mounting the entire disc won't work. Greetz, Joost - Joost van Dongen Lead programmer / co-founder Ronimo Gameswww.ronimo-games.com 2011/8/4 Cooke, Mark > > -Original Message- > > From: joostdon...@gmail.com [mailto:joostdon...@gmail.com] On > > Behalf Of Joost van Dongen > > Sent: 04 August 2011 08:11 > > To: Cooke, Mark > > Cc: Stefan Sperling; users@subversion.apache.org > > Subject: Re: SVN errors with junction points > > > > As Mark guessed, I am indeed setting up the junction points > > by hand. This is how I made it: > > > > -Create folder D:\SVN > > -Do checkout on D:\SVN with "Immediate children, including > > folders", so only the folders come in and not their contents > > -Do "fully recursive" update on D:\SVN\SmallFolder to get its contents > > -Create folder E:\SVN > > -Do checkout on E:\SVN with "Immediate children, including folders" > > -Do "fully recursive" update on E:\SVN\BigFolder > > -Remove the .svn folder from D:\SVN\BigFolder to make it > > actually empty (required for junction points) > > -Create junction point from D:\SVN\BigFolder to E:\SVN\BigFolder > > > > That's it! To Windows Explorer, D:\SVN now looks like a > > complete checkout. However, SVN now gives the errors I posted > > previously. > > Hmm, I've not used mount points much. Do you have anything else on the e:\ > drive? How about using Disk Manager to remove the e:\ drive and mount it > directly as D:\SVN\BigFolder (The "Mount in the following empty NTFS folder" > option)? Then you should be able to do the checkout properly... > > Note: I cannot try this at the moment so YMMV! > > ~ mark c
External refs and proxy
Hello, I want to checkout a repo on the net. I am behind a proxy server. Have configured the proxy in subversion config file. But when I do a checkout I get : svn: warning: Error handling externals definition for 'gnustep/modules': svn: warning: Can't connect to host 'svn.gna.org': Connection timed out How can I go around this problem ? Regards
not storing diffs of binary files
I'm trying to understand why subversion isn't just storing diffs of some binary files. It looks like it's taking up more space than it needs to. At length the issue is described here: http://stackoverflow.com/q/6917505/277208 The more summarized version is... I understand that subversion stores files differentially (compressed), even for binary files. And subversion uses Xdelta to help with this. I can do a standalone xdelta on my 50MB zip files: xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip v1v2_delta.file and get a nicely small v1v2_delta.file which is about 3MB. But when I check successive versions of the data.zip into a subversion repository (FSFS, version 1.6.11) I get two ~50MB files in db\revs\0 I appreciate minimizing disk usage isn't the only thing, e.g. performance may be more important. Being able to configure this would be useful in my situation. I've spent a long time trying to figure out what is going on and not got very far. I guess this behaviour is probably deliberate - it would be really interesting to have an idea of different factors deciding subversion behaving in this way. Thanks Jon
Re: not storing diffs of binary files
On Mon, Aug 8, 2011 at 12:49 PM, Jon Stafford wrote: > I'm trying to understand why subversion isn't just storing diffs of some > binary files. It looks like it’s taking up more space than it needs to.** > ** > > ** ** > > At length the issue is described here: > http://stackoverflow.com/q/6917505/277208 > > ** ** > > The more summarized version is... > > ** ** > > I understand that subversion stores files differentially (compressed), even > for binary files. And subversion uses Xdelta to help with this. > > ** ** > > I can do a standalone xdelta on my 50MB zip files: > > xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip > v1v2_delta.file > > ** ** > > and get a nicely small v1v2_delta.file which is about 3MB. > > ** ** > > But when I check successive versions of the data.zip into a subversion > repository (FSFS, version 1.6.11) I get two ~50MB files in db\revs\0 > > ** ** > > I appreciate minimizing disk usage isn't the only thing, e.g. performance > may be more important. Being able to configure this would be useful in my > situation. > > ** ** > > I've spent a long time trying to figure out what is going on and not got > very far. I guess this behaviour is probably deliberate - it would be > really interesting to have an idea of different factors deciding subversion > behaving in this way. > There are no knobs you can turn, and SVN internally does not have any heuristics it goes through where it decides not to produce deltas. It always produces deltas, even when it is a waste of CPU to do so. However, the fsfs backend also uses a technique called "skip-deltas" which you can read about here: http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas Have you only done two commits of this file? Reading the above note, it looks like the first two revisions of the file are stored as full revisions. -- Thanks Mark Phippard http://markphip.blogspot.com/
Python optional location in centos 5 for compiling from source
Hy all of you, I'm running under centos 5.6 and I would like to use submin that requires python2.5 instead of the 2.4 availbale in the yum. So I successfully installed the python 2.5 in the /opt directory. Unfortunately, all the subversion python files given by the official pacckages are located in the 2.4 python path so taht the /opt/python2.5 instructions aren't able to manage with the libraries. Naturally I suppose that I muste compile from source the svn in against the python2.5 path. I you think I'm not wrong, could you help me on the configure process? Regards from france, Florent THOMAS
Re: not storing diffs of binary files
A quick test in a new repository shows that delta storages is used for the second revision of a file. % svn add iota % svn ci -mm % echo>>iota % svn ci -mm % svn info iota Last Changed Revision: 2 % grep DELTA ../r1/db/revs/0/2 Binary file 2 matches Mark Phippard wrote on Mon, Aug 08, 2011 at 13:31:58 -0400: > On Mon, Aug 8, 2011 at 12:49 PM, Jon Stafford > wrote: > > > I'm trying to understand why subversion isn't just storing diffs of some > > binary files. It looks like it’s taking up more space than it needs to.** > > ** > > > > ** ** > > > > At length the issue is described here: > > http://stackoverflow.com/q/6917505/277208 > > > > ** ** > > > > The more summarized version is... > > > > ** ** > > > > I understand that subversion stores files differentially (compressed), even > > for binary files. And subversion uses Xdelta to help with this. > > > > ** ** > > > > I can do a standalone xdelta on my 50MB zip files: > > > > xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip > > v1v2_delta.file > > > > ** ** > > > > and get a nicely small v1v2_delta.file which is about 3MB. > > > > ** ** > > > > But when I check successive versions of the data.zip into a subversion > > repository (FSFS, version 1.6.11) I get two ~50MB files in db\revs\0 > > > > ** ** > > > > I appreciate minimizing disk usage isn't the only thing, e.g. performance > > may be more important. Being able to configure this would be useful in my > > situation. > > > > ** ** > > > > I've spent a long time trying to figure out what is going on and not got > > very far. I guess this behaviour is probably deliberate - it would be > > really interesting to have an idea of different factors deciding subversion > > behaving in this way. > > > > There are no knobs you can turn, and SVN internally does not have any > heuristics it goes through where it decides not to produce deltas. It > always produces deltas, even when it is a waste of CPU to do so. > > However, the fsfs backend also uses a technique called "skip-deltas" which > you can read about here: > > http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas > > Have you only done two commits of this file? Reading the above note, it > looks like the first two revisions of the file are stored as full revisions. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/
Re: not storing diffs of binary files
On Mon, Aug 8, 2011 at 4:26 PM, Daniel Shahaf wrote: > A quick test in a new repository shows that delta storages is used for > the second revision of a file. > > % svn add iota > % svn ci -mm > % echo>>iota > % svn ci -mm > % svn info iota > Last Changed Revision: 2 > % grep DELTA ../r1/db/revs/0/2 > Binary file 2 matches > I was going to followup to clarify but since I said to read the doc, I did not bother. All revisions are "deltified" but some are deltified against an empty stream. I do not know if the diagram is accurate, but revisions 1 and 2 of the file are both against the empty stream. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: not storing diffs of binary files
Mark Phippard wrote on Mon, Aug 08, 2011 at 16:28:42 -0400: > On Mon, Aug 8, 2011 at 4:26 PM, Daniel Shahaf wrote: > > > A quick test in a new repository shows that delta storages is used for > > the second revision of a file. > > > > % svn add iota > > % svn ci -mm > > % echo>>iota > > % svn ci -mm > > % svn info iota > > Last Changed Revision: 2 > > % grep DELTA ../r1/db/revs/0/2 > > Binary file 2 matches > > > > I was going to followup to clarify but since I said to read the doc, I did > not bother. > > All revisions are "deltified" but some are deltified against an empty > stream. I do not know if the diagram is accurate, but revisions 1 and 2 of > the file are both against the empty stream. > No. r2 is deltified against r1: % grep -a DELTA /tmp/svn/r1/db/revs/0/2 DELTA 1 605 37 > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/
Re: not storing diffs of binary files
On Mon, 08 Aug 2011 16:28:42 +, Mark Phippard wrote: ... > All revisions are "deltified" but some are deltified against an empty > stream. I do not know if the diagram is accurate, but revisions 1 and 2 of > the file are both against the empty stream. Revision 0 goes as a regular revision in that diagram, according to the text. This way every rev but the first is deltified; would be stupid otherwise. (And the first is deltified against the empty stream.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Python optional location in centos 5 for compiling from source
On Mon, Aug 8, 2011 at 3:38 PM, Florent THOMAS wrote: > Hy all of you, > > I'm running under centos 5.6 and I would like to use submin that requires > python2.5 instead of the 2.4 availbale in the yum. > So I successfully installed the python 2.5 in the /opt directory. > Unfortunately, all the subversion python files given by the official > pacckages are located in the 2.4 python path so taht the /opt/python2.5 > instructions aren't able to manage with the libraries. > Naturally I suppose that I muste compile from source the svn in against the > python2.5 path. > I you think I'm not wrong, could you help me on the configure process? > > Regards from france, > > Florent THOMAS > Is there any reason you can't simply jump to CentOS 6, or Scientific Linux or RHEL 6? This is precisely the kind of mix and match backporting that can suck your workweek out thorugh your ears.
Re: 1.7 'svn upgrade' issue on windows vista
On Friday 05 August 2011, Ryan Schmidt wrote: > On Aug 4, 2011, at 18:04, Stephen Meechan wrote: > > The problem was that the svn upgrade command is case sensitive on the WC > > folder name and failed if the name doesn't match exactly. Windows itself > > is case insensitive and none of the other svn commands are case > > sensitive to the WC folder name. > > That is correct. The Subversion client, and a Subversion repository, are > always case-sensitive, regardless of whether your local filesystem is > case-sensitive or not. I don't believe this is considered a bug. So be > careful to specify things with the correct case. I don't think the folder containing the root of a WC should have to have the exact same name as the folder in the repository it corresponds to. As this is a feature to me, I hope that 1.7 isn't going to break this. For example, I have multiple working copies in the same folder but all pointing to the same repository URL. In particular, there is one named "-tmp" for small changes that are split off larger changes and one named "-clean" where I make sure that I didn't break anything for others. Uli -- ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html FAQ: http://subversion.apache.org/faq.html Docs: http://svnbook.red-bean.com/ ** 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. **
