Re: Issue with merge
On Thu, Jun 16, 2011 at 10:21:49PM -0500, Henry Piñeros wrote: 7. Again, I do a checkout from trunk (C:/Trunk). 8. svn merge *https**://example-test-project.googlecode.com/svn/trunk/src/* *https**:// example-test-project.googlecode.com/svn/branches/branchPrueba/src/* I think you should try to use this syntax instead: cd c:\trunk svn merge --reintegrate https://example-test-project.googlecode.com/svn/branches/branchPrueba/ C Hola1.java … Shows a message to resolve conflict between fonts Tomorrow, I going to post here!! (with images) No, please do not post images to this list. You may link to them if you have them somewhere on the web, but please do not attach them. Mail you send to this list goes to a huge number of mail boxes so please try to use only text to keep the messages small. Thanks!
Re: User Template
On Jun 17, 2011, at 02:47, Hrishikesh Gokhale wrote: I am new to SVN installation . I am unable to find a way to add a custom template which would get fired up when a user performs a commit (in his editor) Subversion doesn't have this feature, sorry. You may be able to work around this by writing a custom EDITOR program.
Re: Problem Loading Huge Repository
On Thu, Jun 16, 2011 at 8:08 PM, Bruno Antunes b...@dei.uc.pt wrote: Just a thought... Do you need the revision history or only the current (head) revision? Guessing if you do not need the revision history then it will be much smaller and faster to svn export their-stuff -r HEAD I need the entire revision history, because I need to extract historical information from the repository. But I could use the revision history from specific projects only, I don't need the entire repository, which contains all the ASF projects. The problem is I can filter these projects in the dump file. Why don't you just use the repository of another open-source project that is a better size? It is not like there are a shortage of open-source projects using Subversion available on the open internet. Why use the ASF repository if extracting the history of a single project in that repository would suffice? TortoiseSVN has a decent sized repository: http://code.google.com/p/tortoisesvn/ -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Problem Loading Huge Repository
On 6/16/2011 7:05 PM, Bruno Antunes wrote: Do you know any faster way to load the dump file or to filter out some projects/revisions so I can speed up the process? Are you CPU-bound? Or are you limited by disk speed? If you're limited by disk access times, make sure that the source file that you're loading from is on a different disk then the destination repository. Even if you toss the 45GB dump file onto a USB2 external disk, you'll see a speed increase. And if you have a choice of file systems for the repository to be stored on, make sure that it's something which can deal with a few hundred thousand tiny files. On Linux, I'd suggest going with ext4 over ext3. While db/revs in a FSFS repository can have its revisions packed to reduce the file count, the db/revprops folder still consists of 1 tiny file for every revision in the project in a FSFS repository.
Re: Problem Loading Huge Repository
Thomas Harold wrote on Fri, Jun 17, 2011 at 10:31:43 -0400: On 6/16/2011 7:05 PM, Bruno Antunes wrote: Do you know any faster way to load the dump file or to filter out some projects/revisions so I can speed up the process? Are you CPU-bound? Or are you limited by disk speed? If you're limited by disk access times, make sure that the source file that you're loading from is on a different disk then the destination repository. Even if you toss the 45GB dump file onto a USB2 external disk, you'll see a speed increase. And if you have a choice of file systems for the repository to be stored on, make sure that it's something which can deal with a few hundred thousand tiny files. On Linux, I'd suggest going with ext4 over ext3. While db/revs in a FSFS repository can have its revisions packed to reduce the file count, the db/revprops folder still consists of 1 tiny file for every revision in the project in a FSFS repository. revprops/ is sharded. And in 1.7 (including the recent 1.7.0-alpha1) it is packed, too.
Re: Issue with merge
Hi all. http://twitpic.com/5ctrar/full There are a picture of my issue!!! On Fri, Jun 17, 2011 at 2:32 AM, Stefan Sperling s...@elego.de wrote: On Thu, Jun 16, 2011 at 10:21:49PM -0500, Henry Piñeros wrote: 7. Again, I do a checkout from trunk (C:/Trunk). 8. svn merge *https**:// example-test-project.googlecode.com/svn/trunk/src/* *https**:// example-test-project.googlecode.com/svn/branches/branchPrueba/src/* I think you should try to use this syntax instead: cd c:\trunk svn merge --reintegrate https://example-test-project.googlecode.com/svn/branches/branchPrueba/ C Hola1.java … Shows a message to resolve conflict between fonts Tomorrow, I going to post here!! (with images) No, please do not post images to this list. You may link to them if you have them somewhere on the web, but please do not attach them. Mail you send to this list goes to a huge number of mail boxes so please try to use only text to keep the messages small. Thanks! -- Estudiante de Ingenieria de Sistemas e Informatica Univesidad Nacional de Colombia Sede Medellin 2011
Re: Problem Loading Huge Repository
On 6/17/2011 10:54 AM, Daniel Shahaf wrote: Thomas Harold wrote on Fri, Jun 17, 2011 at 10:31:43 -0400: And if you have a choice of file systems for the repository to be stored on, make sure that it's something which can deal with a few hundred thousand tiny files. On Linux, I'd suggest going with ext4 over ext3. While db/revs in a FSFS repository can have its revisions packed to reduce the file count, the db/revprops folder still consists of 1 tiny file for every revision in the project in a FSFS repository. revprops/ is sharded. And in 1.7 (including the recent 1.7.0-alpha1) it is packed, too. Good. Another of the many reasons that we're looking forward to 1.7. Even with the sharding, those little revprop files are causing us issues during backups (hotcopy - rdiff-backup). Being able to pack those revprop files is going to make a big difference as the backup process will only have to track 2000-2200 files instead of 30,000 to 50,000. (We have a few long-lived repositories with up to 25k revisions. And I just finished splitting a 22GB repository with 15-16k revs into a bunch of smaller repositories. Now the nightly backup can look at doing a hotcopy on only the repositories with changes in the last 5 days.)
Re: Problem Loading Huge Repository
Thomas Harold wrote on Fri, Jun 17, 2011 at 11:50:45 -0400: On 6/17/2011 10:54 AM, Daniel Shahaf wrote: Thomas Harold wrote on Fri, Jun 17, 2011 at 10:31:43 -0400: And if you have a choice of file systems for the repository to be stored on, make sure that it's something which can deal with a few hundred thousand tiny files. On Linux, I'd suggest going with ext4 over ext3. While db/revs in a FSFS repository can have its revisions packed to reduce the file count, the db/revprops folder still consists of 1 tiny file for every revision in the project in a FSFS repository. revprops/ is sharded. And in 1.7 (including the recent 1.7.0-alpha1) it is packed, too. Good. Another of the many reasons that we're looking forward to 1.7. Even with the sharding, those little revprop files are causing us issues during backups (hotcopy - rdiff-backup). Being able to pack those revprop files is going to make a big difference as the backup process will only have to track 2000-2200 files instead of 30,000 to 50,000. (We have a few long-lived repositories with up to 25k revisions. And I just finished splitting a 22GB repository with 15-16k revs into a bunch of smaller repositories. Now the nightly backup can look at doing a hotcopy on only the repositories with changes in the last 5 days.) See also: http://subversion.tigris.org/issues/show_bug.cgi?id=3815
Performance
Hi everybody, is there somewhere some documentation about svn performance(CPU/Network) other than the one at IBM pages? regards Thomas
Re: Apache Subversion 1.7.0-alpha1 Released
On Fri, Jun 10, 2011 at 09:08:33AM -0500, Hyrum Wright wrote: I'm happy to announce Apache Subversion 1.7.0-alpha1, the first public pre-release of the 1.7.x series, is now available. Please choose the closest mirror to you by visiting: http://subversion.apache.org/download/#pre-releases This is the first public release for what will eventually become Apache Subversion 1.7.0. The term 'alpha' means the Subversion developers feel that this release is ready for widespread testing by the community. There are known issues (and unknown ones!), so please use it at your own risk, though we do encourage people to test this release thoroughly. For those who would like to test pre-releases of Subversion 1.7 but don't want to compile their own binaries, we've added links to binary packages provided by various members of the Subversion community on our packages page. See http://subversion.apache.org/packages.html#pre-release Currently, binaries are available for the following operating systems: Win32, Redhat/Centos, and SUSE Linux. We'll add more to the list as they become available. Release notes for the 1.7.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.7.html
RE: Merge tracking bug - inherited merge-range
Now that I have a 1.7-alpha client, I gave this scenario I posted last month another try, and it works fine. Not a problem for 1.7. -Steve From: Varnau, Steve (Neoview) Sent: Monday, May 09, 2011 6:06 PM To: users@subversion.apache.org Cc: Brackett, Faye Subject: Merge tracking bug - inherited merge-range Greetings, I have a merge tracking bug to report. It seems like there are a lot of steps to re-produce it, but we discovered this in the real world, and it took a long while to figure out what was going on and to re-produce it. We are running 1.6.15 clients. We have lots of branching, and unfortunately svn:mergeinfo at multiple levels. This bug apparently only shows up if you merge two levels of directory that have new mergeinfo properties. The lower level directory does not get updated correctly and causes duplicate merge conflicts later. Yes, I know best practice says to merge only at the top-level, but in a large project, those merge-tracking properties can grow like weeds. The example steps below to reproduce use multiple branches just to produce the mergeinfo at multiple directory levels. There might be a simpler way to reproduce it. I did not find anything in the issue tracker, and I have not tried this with 1.6.16 or with pre-release 1.7. -Steve # create sub-directory tree $ svn co file:///c:/temp/svn-test/trunkfile:///c:\temp\svn-test\trunk trunk-wc $ cd trunk-wc/ $ svn mkdir subA $ svn mkdir subA/subB $ svn ci -m need 2 directories $ svn cp ^/trunk ^/branch/br1 # first branch adds some content $ cd .. $ svn co file:///c:/temp/svn-test/branch/br1file:///c:\temp\svn-test\branch\br1 br1-wc $ cd br1-wc/subA $ touch foo $ touch subB/bar $ svn add foo subB/bar $ svn ci -m br1 adds # second project branch picks up the directories before project 1 delivers # third and forth start later $ cd ../.. $ cd trunk-wc/ $ svn cp ^/trunk ^/branch/br2 -m victim project $ svn merge --reintegrate ^/branch/br1 $ svn ci -m $ svn cp ^/trunk ^/branch/br3 -m foo project $ svn cp ^/trunk ^/branch/br4 -m bar project # three projects working concurrently, project 3 4 make changes $ cd .. $ svn co file:///c:/temp/svn-test/branch/br2file:///c:\temp\svn-test\branch\br2 br2-wc $ svn co file:///c:/temp/svn-test/branch/br3file:///c:\temp\svn-test\branch\br3 br3-wc $ svn co file:///c:/temp/svn-test/branch/br4file:///c:\temp\svn-test\branch\br4 br4-wc $ cd br3-wc/subA/ $ echo change foo $ svn ci -m $ cd ../../br4-wc/subA/subB/ $ echo change bar $ svn ci -m # project 2 first synchs up the changes from br1 $ cd ../../../br2-wc/ $ svn merge ^/trunk $ svn ci -m synch 1 $ svn up At revision 88. # project 3 4 each deliver content AND incidentally add svn:merginfo properties to subA subB $ cd ../trunk-wc/subA/subB/ $ svn up $ svn merge --reintegrate ^/branch/br4/subA/subB $ svn ci -m deliver bar Committed revision 89. $ cd .. $ svn up $ svn merge --reintegrate ^/branch/br3/subA $ svn ci -m deliver foo Committed revision 90. # project 2 synchs up again, including svn:mergeinfo $ cd ../../br2-wc/ $ svn merge ^/trunk --- Merging r88 through r90 into '.': UsubA\foo UsubA\subB\bar U subA\subB U subA # at this point mergeinfo is correct for subA, but not for subB # The content looks okay, so we check in and try another synch merge # Even though nothing changed on trunk, we get duplicate merge conflict $ svn ci -m synch 2 $ svn up At revision 91. $ svn merge ^/trunk --- Merging r82 through r87 into 'subA\subB': C subA\subB\bar Summary of conflicts: Tree conflicts: 1
