Re: Building issue.
Hi Daniel, by Using; > make install; echo $? It does indeed exit with a 0. Thanks. I don;' know how - but I completely missed the subversion directory that was created! I possibly, simply, assumed it was from trunk. I can also confirm from a dev-point of view, That trunk passes all tests via make check on my Mac too. Off to have a play! - thanks again. Gavin. On 14/04/2011, at 3:45 PM, Daniel Shahaf wrote: > On Thu, 14 Apr 2011 14:49 +1000, "Gavin Beau Baumanis" > wrote: >> Hi Everyone, >> I am trying to build SVN from source code on my Mac (OS X 10.6.6) >> >> I have checked out the code from trunk and have all the dependencies >> available too; >> >> Following INSTALL; >> sh ./autogen.sh >> ./configure >> make >> make install >> >> however when I run make install I get the following error; >> svn: E155036: Working copy >> '/Users/gavin/Subversion/sourcecode/subversion/trunk' is too old (format >> 10, created by Subversion 1.6) >> >> which seems straight forward, >> But how do you get a later format, without building a newer binary? >> > > By running 'subversion/svn/svn upgrade'. (but see below --- you > shouldn't need to upgrade your working copy) > >> It seems circular, or am I missing something simple? >> > > Most likely yes. You didn't paste the complete 'make' output, but I bet > that you get the error during the very last step (which runs svnversion > on your working copy). In which case, have a look at the > 'revision-install' target of the Makefile --- most likely the error > you're seeing can be ignored, since the Makefile tries both the just-built > svnversion and the system's svnversion. > > Didn't 'make install' have exit code of zero? > > (You can check by 'make install; echo $?') > >> >> >> As always, Thanks in advance! >> >> Gavin.
RE: duplicate merge conflict
> When I merge changes in SVN, the merges work well except for the > conflicts. For some reason, the merges are frequently (but not > always done twice). As an example: > <<< .working > <<< .working > const int SERIALIZE_FIELDS_DATA_LENGTH = 83; > === > const int SERIALIZE_FIELDS_DATA_LENGTH = 91; > >>> .merge-right.r462 > === > const int SERIALIZE_FIELDS_DATA_LENGTH = 91; > >>> .merge-right.r461 > It appears that I am merging the changes between versions 442 and > 462 into the current working copy so I don't understand where 461 > is coming from. > > This is happening both with Tortoise SVN (using Merge two different > trees) or from the command line with: > > svn merge tree1 tree2 --non-interactive Can you revert your merge and verify that your working copy didn't already have those r461 merge indicators in it. I know here people have checked in files that had unresolved conflict markers in them. BOb
Re: svnsync error : Error while replaying commit
Yes, that was the problem. After fixing the permissions, I initiated another mirror operation that was able to sync everything. The issue was that A had restricted access and a branch 'B' was created from A for public use. Since A was missing in the mirrored branch, the mirror operation failed However even though the error happened due to incorrect authentication scripts, the error message should have included some details about the problem. When I googled for this generic error message, there was lot of crap but no solution. I had to spend almost half a day to narrow down this issue. Thanks Ankush From: Thorsten Schöning To: users@subversion.apache.org Sent: Wed, April 13, 2011 3:27:30 AM Subject: Re: svnsync error : Error while replaying commit Guten Tag ankush chadha, am Dienstag, 12. April 2011 um 18:46 schrieben Sie: > Is there any way to get around this problem. I updated all the permissions but > the problem is that A was created like years back and I won't be able to mirror > those revisions. Access restrictions are not versioned with the data, they are read from the configuration at the moment one wants to access the data. Therefore it should make no difference when your folder A was created and if the user used to sync now still can't read folder A, then your access configuration is just wrong and needs to be tuned. The easiest thing to test would be to create a new user just for syncing an give him full access to everything. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web:http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Massive file duplication with several working copies / which linux filesystem to use
Hi all, We have 5 developers, each of them has a workspace on our linux workgroup server. The workspaces constist of working copies checked out from our SVN repository. The workspaces have grown rather big in our case, we have like 20 GB per developer. That's a 100 GB worth of working copies of pretty much the same things. If all developers had clean working copies of exactly the same revisions of exactly the same SVN checkouts, this would mean we store each file ten times. (!) Now that's a massive multiplication of bytes. I'm not blaming SVN, it's doing what we want it to do. I'm rather looking one level below, at the filesystem that stores all these workspaces. If the filesystem could do online deduplication, it would mean a huge saving on disk capacity for us. We would also like to move the workspaces to a solid-state drive, for faster builds. Which linux filesystem would you recommend? Jan Dvorak
Re: svnsync error : Error while replaying commit
"It should work." Specifically, if you run svnsync using an authz-bound user, then you should just see adds-with-history converted into adds-without-history. I believe we have regression tests for such scenarios too. If you can reproduce this (have a minimal example), please file an issue, thanks. Daniel (separately: is the error in the subject really everything? It should be logging the original error somewhere --- possibly on the server side, but *somewhere*.) On Thu, 14 Apr 2011 07:13 -0700, "ankush chadha" wrote: > Yes, that was the problem. After fixing the permissions, I initiated > another mirror operation that was able to sync everything. > > The issue was that A had restricted access and a branch 'B' was > created from A for public use. Since A was missing in the mirrored > branch, the mirror operation failed > > However even though the error happened due to incorrect authentication > scripts, the error message should have included some details about the > problem. When I googled for this generic error message, there was lot > of crap but no solution. I had to spend almost half a day to narrow > down this issue. > > Thanks > Ankush > > > > > > > From: Thorsten Schöning > To: users@subversion.apache.org > Sent: Wed, April 13, 2011 3:27:30 AM > Subject: Re: svnsync error : Error while replaying commit > > Guten Tag ankush chadha, > am Dienstag, 12. April 2011 um 18:46 schrieben Sie: > > > Is there any way to get around this problem. I updated all the permissions > > but > > the problem is that A was created like years back and I won't be able to > > mirror > > those revisions. > > Access restrictions are not versioned with the data, they are read > from the configuration at the moment one wants to access the data. > Therefore it should make no difference when your folder A was created > and if the user used to sync now still can't read folder A, then your > access configuration is just wrong and needs to be tuned. > > The easiest thing to test would be to create a new user just for > syncing an give him full access to everything. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning > AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig > > Telefon: Potsdam: 0331-743881-0 > E-Mail: tschoen...@am-soft.de > Web:http://www.am-soft.de > > AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam > Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
RE: Subversion, symbolic links, and CIFS mounts
Do you use option 'nbrl' when mounting? Like this (in stab): //winserver/repo /opt/csvn/data/repositories cifs \ nobrl,user=csvn,password=***,rw,uid=csvn,gid=csvn, \ dir_mode=0755,file_mode=0755 0 0
Re: Massive file duplication with several working copies / which linux filesystem to use
Guten Tag Jan Dvorak, am Donnerstag, 14. April 2011 um 16:16 schrieben Sie: > Which linux filesystem would you recommend? The only one I read of with deduplication was ZFS and KQ Infotech seems to provide a good implementation for Linux. http://www.kqinfotech.com/content.php?id=2 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Using tags with SVN
On 4/1/2011 7:52 AM, Stirnweiss, Siegmund SZ/HZA-ZIT3 wrote: Sometimes you can adjust a tag if you've tagged the wrong file, but that should be fairly rare. In Subversion, tags take less than a second to do while in CVS, you have to tag each and every file. Long files have to be rewritten after every tag. That, to me is a great advantage in Subversion. Having to tag each and every file in cvs for us is a feature. It helps us achieving our goal in a very convenient way. In cvs, you _have_ to tag files to get any sort of grouping. It is the only way to tie a set of files at specific revisions together. Svn works naturally with directories, so normally you want to replace the concept of using tags on files to hold a group together with organizing the layout under directories (which probably already exist...) and using the repository global revision number for a particular state. We use tags in CVS to identify the files which have passed module tests and should make it into our integration test environment. When they have passed the integration tests we use a different tag to identify the files, which make up the software in/for our production environment. In addition to that our development model is not release driven. As a result we do not tag the HEAD of our complete source tree at a particular point in time. Whoa! That's dangerous. When you pick and choose tags, you may end up tagging the wrong file. Then, this is a CM error and not a developer error. That means the Finger o' Blame points to you and not to the developer who gave you the wrong file or forgot a file. You want that Finger o' Blame pointing not at you. That's not the problem here. The developers themselves tag files and we have not yet had a problem with this approach. In svn, you might want to use a more directory-oriented approach. It would be more typical to copy the top level project to a QA/release branch and keep making changes there until all the files pass QA, perhaps making tag copies as you go, but you could copy file-by-file into the branch if you don't want them to appear all at once. Now, there's nothing in Subversion preventing you from attaching a tag to a particular version of a file. You simply copy files to the tag directory one at a time. When a file gets approved, you "tag" it. It's not the standard way to do it, but I've seen shops that do. What exactly do you mean with copy? Do you mean a "svn copy"? Or do you mean a file system copy? Always "svn copy" - but it can be in some developer's working copy that is subsequently committed or a url->url repository operation. -- Les Mikesell lesmikes...@gmail.com
Re: Advice on upgrading svn and moving to new server
On 4/1/2011 7:45 AM, KM wrote: Thanks I think. Not sure it helps with my original question. ... which i am sure i'll figure out by trial and error. Whether to updgrade to solaris 10 w/new server, install newer svn and dependent packages and then copy reppos from old server - dump it and load it. Or do I need to install and upgraded svn and repos on old server then copy to new server - etc - Dump/load is supposed to 'always' work and gives the system a change to optimize storage. Upgrade-in-place should work too, but may not optimize to new formats, and copying the binary repo files might only work across similar CPU types. Yet another alternative would be to use svnsync to pull the content from the old to the new server, then adjust the hooks to become an active repository. -- Les Mikesell lesmikes...@gmail.com
Re: duplicate merge conflict
I reverted to the original source and verified it. It had no conflicts. Then I did the merge again. The same thing happened and I ended up with duplicate conflicts again. -- From: "Bob Archer" Sent: Thursday, April 14, 2011 9:33 AM To: "Daniel Walter" ; Subject: RE: duplicate merge conflict When I merge changes in SVN, the merges work well except for the conflicts. For some reason, the merges are frequently (but not always done twice). As an example: <<< .working <<< .working const int SERIALIZE_FIELDS_DATA_LENGTH = 83; === const int SERIALIZE_FIELDS_DATA_LENGTH = 91; >>> .merge-right.r462 === const int SERIALIZE_FIELDS_DATA_LENGTH = 91; >>> .merge-right.r461 It appears that I am merging the changes between versions 442 and 462 into the current working copy so I don't understand where 461 is coming from. This is happening both with Tortoise SVN (using Merge two different trees) or from the command line with: svn merge tree1 tree2 --non-interactive Can you revert your merge and verify that your working copy didn't already have those r461 merge indicators in it. I know here people have checked in files that had unresolved conflict markers in them. BOb
RE: duplicate merge conflict
> -- > From: "Bob Archer" > Sent: Thursday, April 14, 2011 9:33 AM > To: "Daniel Walter" ; > > Subject: RE: duplicate merge conflict > > >> When I merge changes in SVN, the merges work well except for the > >> conflicts. For some reason, the merges are frequently (but not > >> always done twice). As an example: > >> <<< .working > >> <<< .working > >> const int SERIALIZE_FIELDS_DATA_LENGTH = 83; > >> === > >> const int SERIALIZE_FIELDS_DATA_LENGTH = 91; > >> >>> .merge-right.r462 > >> === > >> const int SERIALIZE_FIELDS_DATA_LENGTH = 91; > >> >>> .merge-right.r461 > >> It appears that I am merging the changes between versions 442 > and > >> 462 into the current working copy so I don't understand where > 461 > >> is coming from. > >> > >> This is happening both with Tortoise SVN (using Merge two > different > >> trees) or from the command line with: > >> > >> svn merge tree1 tree2 --non-interactive > > > > Can you revert your merge and verify that your working copy > didn't already > > have those r461 merge indicators in it. I know here people have > checked in > > files that had unresolved conflict markers in them. > > > I reverted to the original source and verified it. It had no > conflicts. > Then I did the merge again. The same thing happened and I ended up > with > duplicate conflicts again. > Is it possible you are merging in a range of non-contiguous revision? I believe that does a merge of each range separately. BOb
Re: duplicate merge conflict
It is possible that there are two ranges. It is not my intent to have these two ranges, it would just be from the mechanics of svn copy. I have recently switched from CVS where I did merges with tags. I am attempting to use svn copy to do the same thing. I make a new tag (svn copy) in my production version source every time I merge changes forward into my development version. Then I do an svn merge between the prior tag I created this way (svn://192.168.0/tags/one-month-ago) and the current tag (svn://192.168.0/tags/just-created). In the example that I had given 461 would be the last commit before the svn copy and 462 is the svn copy itself. -- From: "Bob Archer" Sent: Thursday, April 14, 2011 1:38 PM To: "Daniel Walter" ; Subject: RE: duplicate merge conflict -- From: "Bob Archer" Sent: Thursday, April 14, 2011 9:33 AM To: "Daniel Walter" ; Subject: RE: duplicate merge conflict >> When I merge changes in SVN, the merges work well except for the >> conflicts. For some reason, the merges are frequently (but not >> always done twice). As an example: >> <<< .working >> <<< .working >> const int SERIALIZE_FIELDS_DATA_LENGTH = 83; >> === >> const int SERIALIZE_FIELDS_DATA_LENGTH = 91; >> >>> .merge-right.r462 >> === >> const int SERIALIZE_FIELDS_DATA_LENGTH = 91; >> >>> .merge-right.r461 >> It appears that I am merging the changes between versions 442 and >> 462 into the current working copy so I don't understand where 461 >> is coming from. >> >> This is happening both with Tortoise SVN (using Merge two different >> trees) or from the command line with: >> >> svn merge tree1 tree2 --non-interactive > > Can you revert your merge and verify that your working copy didn't already > have those r461 merge indicators in it. I know here people have checked in > files that had unresolved conflict markers in them. > I reverted to the original source and verified it. It had no conflicts. Then I did the merge again. The same thing happened and I ended up with duplicate conflicts again. Is it possible you are merging in a range of non-contiguous revision? I believe that does a merge of each range separately. BOb
Re: svnsync error : Error while replaying commit
Yeah, even I thought that the behavior should be same as you mentioned but I got "svnsync: Error while replaying commit" error during sync operation for that revision. When I checked the mirrored repository, A was missing which is correct as at that time A had restricted access. Branch operation of A to B failed to mirror though. I am using svn 1.6.6. After fixing the permissions and re-initiating another mirror the problem went away and now both of my repositories are synced up with A and B. I am sure that this was the error but willl try to write reproduction steps with sample scripts. Thanks Ankush From: Daniel Shahaf To: ankush chadha ; Thorsten Schöning ; users@subversion.apache.org Sent: Thu, April 14, 2011 10:21:12 AM Subject: Re: svnsync error : Error while replaying commit "It should work." Specifically, if you run svnsync using an authz-bound user, then you should just see adds-with-history converted into adds-without-history. I believe we have regression tests for such scenarios too. If you can reproduce this (have a minimal example), please file an issue, thanks. Daniel (separately: is the error in the subject really everything? It should be logging the original error somewhere --- possibly on the server side, but *somewhere*.) On Thu, 14 Apr 2011 07:13 -0700, "ankush chadha" wrote: > Yes, that was the problem. After fixing the permissions, I initiated > another mirror operation that was able to sync everything. > > The issue was that A had restricted access and a branch 'B' was > created from A for public use. Since A was missing in the mirrored > branch, the mirror operation failed > > However even though the error happened due to incorrect authentication > scripts, the error message should have included some details about the > problem. When I googled for this generic error message, there was lot > of crap but no solution. I had to spend almost half a day to narrow > down this issue. > > Thanks > Ankush > > > > > > > From: Thorsten Schöning > To: users@subversion.apache.org > Sent: Wed, April 13, 2011 3:27:30 AM > Subject: Re: svnsync error : Error while replaying commit > > Guten Tag ankush chadha, > am Dienstag, 12. April 2011 um 18:46 schrieben Sie: > > > Is there any way to get around this problem. I updated all the permissions >but > > the problem is that A was created like years back and I won't be able to > > mirror > > those revisions. > > Access restrictions are not versioned with the data, they are read > from the configuration at the moment one wants to access the data. > Therefore it should make no difference when your folder A was created > and if the user used to sync now still can't read folder A, then your > access configuration is just wrong and needs to be tuned. > > The easiest thing to test would be to create a new user just for > syncing an give him full access to everything. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning > AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig > > Telefon: Potsdam: 0331-743881-0 > E-Mail: tschoen...@am-soft.de > Web:http://www.am-soft.de > > AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam > Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: svnsync error : Error while replaying commit
On Thu, 14 Apr 2011 11:17 -0700, "ankush chadha" wrote: > Yeah, even I thought that the behavior should be same as you mentioned > but I got "svnsync: Error while replaying commit" error during sync > operation for that revision. > > > When I checked the mirrored repository, A was missing which is correct > as at that time A had restricted access. Branch operation of A to B > failed to mirror though. > > I am using svn 1.6.6. After fixing the permissions and re-initiating > another mirror the problem went away and now both of my repositories > are synced up with A and B. I am sure that this was the error but > willl try to write reproduction steps with sample scripts. > That would help a lot, thanks, Daniel > Thanks > Ankush > > > > > > > > From: Daniel Shahaf > To: ankush chadha ; Thorsten Schöning > ; users@subversion.apache.org > Sent: Thu, April 14, 2011 10:21:12 AM > Subject: Re: svnsync error : Error while replaying commit > > "It should work." > > Specifically, if you run svnsync using an authz-bound user, then you > should just see adds-with-history converted into adds-without-history. > I believe we have regression tests for such scenarios too. > > If you can reproduce this (have a minimal example), please file an > issue, thanks. > > Daniel > (separately: is the error in the subject really everything? It should > be logging the original error somewhere --- possibly on the server side, > but *somewhere*.) > > > On Thu, 14 Apr 2011 07:13 -0700, "ankush chadha" > > wrote: > > Yes, that was the problem. After fixing the permissions, I initiated > > another mirror operation that was able to sync everything. > > > > The issue was that A had restricted access and a branch 'B' was > > created from A for public use. Since A was missing in the mirrored > > branch, the mirror operation failed > > > > However even though the error happened due to incorrect authentication > > scripts, the error message should have included some details about the > > problem. When I googled for this generic error message, there was lot > > of crap but no solution. I had to spend almost half a day to narrow > > down this issue. > > > > Thanks > > Ankush > > > > > > > > > > > > > > From: Thorsten Schöning > > To: users@subversion.apache.org > > Sent: Wed, April 13, 2011 3:27:30 AM > > Subject: Re: svnsync error : Error while replaying commit > > > > Guten Tag ankush chadha, > > am Dienstag, 12. April 2011 um 18:46 schrieben Sie: > > > > > Is there any way to get around this problem. I updated all the > > > permissions > >but > > > the problem is that A was created like years back and I won't be able to > > > mirror > > > those revisions. > > > > Access restrictions are not versioned with the data, they are read > > from the configuration at the moment one wants to access the data. > > Therefore it should make no difference when your folder A was created > > and if the user used to sync now still can't read folder A, then your > > access configuration is just wrong and needs to be tuned. > > > > The easiest thing to test would be to create a new user just for > > syncing an give him full access to everything. > > > > Mit freundlichen Grüßen, > > > > Thorsten Schöning > > > > -- > > Thorsten Schöning > > AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig > > > > Telefon: Potsdam: 0331-743881-0 > > E-Mail: tschoen...@am-soft.de > > Web:http://www.am-soft.de > > > > AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam > > Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow >
Re: Massive file duplication with several working copies / which linux filesystem to use
2011/4/14 Thorsten Schöning > Guten Tag Jan Dvorak, > am Donnerstag, 14. April 2011 um 16:16 schrieben Sie: > > > Which linux filesystem would you recommend? > > The only one I read of with deduplication was ZFS and KQ Infotech > seems to provide a good implementation for Linux. > > http://www.kqinfotech.com/content.php?id=2 Be careful with ZFS deduplication. It still has some issues. Memory usage for it is quite massive, and there are cases of running a destroy operation on a deduped zpool taking literally days. -- David Brodbeck System Administrator, Linguistics University of Washington
Re: Massive file duplication with several working copies / which linux filesystem to use
On 14.4.2011 21:17, David Brodbeck wrote: [...] Be careful with ZFS deduplication. It still has some issues. Memory usage for it is quite massive, I was prepared for that, yes. and there are cases of running a destroy operation on a deduped zpool taking literally days. I see, that's very good to know. As we have no ambition to be on the bleeding edge, we'd wait a little before we decide for ZFS. -- David Brodbeck System Administrator, Linguistics University of Washington Jan Dvorak
Error with svn diff
We are using Subversion 1.6.16 on a Ubuntu Lucid box, and a Ubuntu Hardy (8.04) box hosting a subversion 1.6.16 repository via apache. We use this configuration to support codestriker 1.9.10 for code reviews, and have recently hit a problem with some of our reviews. After carefully stepping through the codestriker code with some of our affected source code, I found a problem with svn diff The codestriker code checks the summary of lines changed at the top of each diff block against the actual lines in the block, and rejects the diff as malformed if they do not match. On a particular piece of code, the svn diff header claims 33 old lines, when there are actually 32. I have re-run this with an external diff command (svn diff -r 57968:57969 --old --diff-cmd=/usr/bin/diff > out.diff) and the problem goes away. I reverted my subversion installation to 1.6.6, and the problem is still present. I am loathe to post the diff, as the project is somewhat sensitive - we build systems for defence here. Finally, I am away on leave for a week, so cannot reply until after 26th April. -- Tony Butt CEA Technologies
