Lines duplicated in dest. file when merging back to trunk
Hi, I'm not subscribed on your mailing list so it would be great if you could Cc me in you responses. I'm having problems with merges going wrong. In our company we sometimes put the same changes on several branches by hand (the reason for this involves code that has to talk to a legacy system with a very primitive VCS built in to the language itself). But we also merge our branches using svn and we have discovered that our merges sometimes can go wrong. I have some short texts to illustrate what happens and also gives a repo-case: We start out with a file that looks like this both on trunk and on our branch (A is first line in file and D is the last). A B C D Note that there is a space character on the empty line between B and C. Then we make a change on the trunk A B some change C D And on our branch we make almost the same change A B some change C D The only difference between the change on the trunk and on the branch is that the trunk has three space characters on the line between B and some change while the branch still only has one space character. When merging the branch to the trun the result is the following: A B some change some change C D We get no merge conflict, but the text is copied twice into the file on trunk. I've been able to reproduce this with Collabnet, SlikSVN and Tortoise clients using version svn version 1.6. Is this a known issue? Is it possible that it's already fixed in svn 1.7? Best regards Simon
Re: Lines duplicated in dest. file when merging back to trunk
On 06/04/2013 09:16 AM, Saffer, Simon wrote: > I’m not subscribed on your mailing list so it would be great if you could Cc > me in you responses. HTML is a really poor format for emails sent to software discussion lists, *especially* when the contents of the mail rely so heavily on formatting details such as the ability to notice trailing space characters on the lines of a text file. Please re-send your post in plaintext format. -- C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
RE: Lines duplicated in dest. file when merging back to trunk
Hi, I'm resending this email, now hopefully in plain text. Sorry about that. I’m not subscribed on your mailing list so it would be great if you could Cc me in your responses. I’m having problems with merges going wrong. In our company we sometimes put the same changes on several branches by hand (the reason for this involves code that has to talk to a legacy system with a very primitive VCS built in to the language itself). But we also merge our branches using svn and we have discovered that our merges sometimes can go wrong. I have some short texts to illustrate what happens and also gives a repo-case: We start out with a file that looks like this both on trunk and on our branch (A is first line in file and D is the last). A B C D Note that there is a space character on the empty line between B and C. Then we make a change on the trunk A B some change C D And on our branch we make almost the same change A B some change C D The only difference between the change on the trunk and on the branch is that the trunk has three space characters on the line between B and some change while the branch still only has one space character. When merging the branch to the trunk the result is the following: A B some change some change C D We get no merge conflict, but the text is copied twice into the file on trunk. I’ve been able to reproduce this with Collabnet, SlikSVN and Tortoise clients using version svn version 1.6. Is this a known issue? Is it possible that it’s already fixed in svn 1.7? Best regards Simon
large db/revs files
Hi, all – I am not subscribed and would appreciate being explicitly Cc:ed in any responses. I am on a team that began using subversion near the end of last year. As a part of our process, we tag each successful run of our systems. This can mean thousands of tags for certain systems every six months. We’re having an issue with the db/revs directory size, which for all our projects currently exceeds 289G. We only use relatively small working directories containing less than a meg of text files; no binary files. In the archives, I found a mention that the db/revs directories are populated using xdelta, but there didn’t appear to be a solution to large file sizes at time [http://svn.haxx.se/users/archive-2011-08/0229.shtml ]. I was hoping someone may have found a work-around or solution. Would someone be able to: 1) suggest how to avoid this in the future 2) suggest how to reduce the current large files (if possible) Thank you. André Harper
Re: large db/revs files
Guten Tag Andre Harper, am Dienstag, 4. Juni 2013 um 16:30 schrieben Sie: > We’re having an issue with the db/revs directory size, which for all > our projects currently exceeds 289G. We only use relatively small > working directories containing less than a meg of text files; no > binary files. Could you provide some examples of your directory structure especially for all your tags? Are your tags all on the same directory level? If yes, that's probably the reason for large sizes of res files because each commit in a directory replicates the complete directory structure for this directory. There were some discussions about this in the past, which I'm always unable to find again. Below are some hints: Besides that, you could try a complete dump/load cycle to use representation sharing for all your data, but this only helps if your file contents are the problem, of course. http://www.red-bean.com/kfogel/beautiful-code/bc-chapter-02.html http://stackoverflow.com/questions/6917505/inexplicable-svn-repository-size-increase-from-small-differences-to-big-files Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Lines duplicated in dest. file when merging back to trunk
On Tue, 04 Jun 2013 14:09:35 +, Saffer, Simon wrote: ... > > A > B > >some change > >some change > > C > D > > We get no merge conflict, but the text is copied twice into the file on trunk. So, you add one line on trunk, and a different line (and different whitespace mieans 'different') on the branch, and you expect the VCS to drop one of them? It is obvious that both changes should be taken into the merge, arguably (and usually) unless they are exactly the same, so SVN does nothing wrong here. The more interesting part is why you don't even get a conflict. Apparently the exact place you do the modification in are also far enough apart from each other so that the merge algorithm can take them as independent chunks that affect disjunct parts of the original file. You should really go and cherry-pick such changes from one branch to the other. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: large db/revs files
On Tue, Jun 4, 2013 at 7:30 AM, Andre Harper wrote: > Hi, all – > > I am not subscribed and would appreciate being explicitly Cc:ed in any > responses. > > I am on a team that began using subversion near the end of last year. > As a part of our process, we tag each successful run of our systems. > This can mean thousands of tags for certain systems every six months. > > We’re having an issue with the db/revs directory size, which for all > our projects currently exceeds 289G. We only use relatively small > working directories containing less than a meg of text files; no > binary files. > > In the archives, I found a mention that the db/revs directories are > populated using xdelta, but there didn’t appear to be a solution to > large file sizes at time > [http://svn.haxx.se/users/archive-2011-08/0229.shtml > ]. I was hoping someone may have found a work-around or solution. > > Would someone be able to: > 1) suggest how to avoid this in the future > 2) suggest how to reduce the current large files (if possible) 1. Upgrade to 1.8 when it is available. 2. Dump and load your repository 3. Figure out what to do with all of the free disk space you suddenly have. See: http://subversion.apache.org/docs/release-notes/1.8.html#fsfs-deltification -- Thanks Mark Phippard http://markphip.blogspot.com/
Tree conflict on Fresh checkout
We are seeing a strange anomaly after our last check-in - on fresh checkout there is a tree conflict into a new path - I've included the output below. user_dude@computer_node~/projects/my_project $ svn co https://svn.my_company.com/svn/my_project_fw/branches/int/ my_project_03b my_project_03b_pristine Amy_project_03b_pristine/Test Amy_project_03b_pristine/Test/Global Amy_project_03b_pristine/Test/Global/Default Amy_project_03b_pristine/Test/Global/Default/Configuration Amy_project_03b_pristine/Test/Global/Default/Configuration/TEMPLATE.asn ... Amy_project_03b_pristine/Project/settings/run.cmd Amy_project_03b_pristine/Project/settings/MkSharedData.exe C my_project_03b_pristine/Project/settings/MkImage A my_project_03b_pristine/Project/settings/MkImage/main.c A my_project_03b_pristine/Project/settings/MkImage/defs.h A my_project_03b_pristine/Project/settings/MkImage/Makefile Amy_project_03b_pristine/Project/settings/hex_to_hex.exe Amy_project_03b_pristine/Project/settings/composit.cmp Amy_project_03b_pristine/Project/settings/GenCrc.pl ... Amy_project_03b_pristine/Documentation/Architecture.docx Amy_project_03b_pristine/.pydevproject Amy_project_03b_pristine/Makefile Amy_project_03b_pristine/.settings Amy_project_03b_pristine/.settings/org.eclipse.cdt.codan.core.prefs U my_project_03b_pristine Checked out revision 2577. user_dude@computer_node~/projects/my_project $ svn status svn: warning: W155007: '/cygdrive/D/Users/user_dude/projects/my_project' is not a working copy user_dude@computer_node~/projects/my_project $ cd my_project_03b_pristine/ user_dude@computer_node~/projects/my_project/my_project_03b_pristine $ svn status D C Project/settings/MkImage > local unversioned, incoming add upon update D Project/settings/MkImage/Makefile D Project/settings/MkImage/defs.h D Project/settings/MkImage/main.c Summary of conflicts: Tree conflicts: 1 user_dude@computer_node~/projects/my_project/my_project_03b_pristine $ This happens on svn 1.7.9 and 1.7.10, but not 1.7.6, 1.6.13, nor on TortoiseSVN of the last couple of revs. $ svn --version svn, version 1.7.9 (r1462340) compiled Apr 14 2013, 10:11:47 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme $ svn --version svn, version 1.7.10 (r1485443) compiled Jun 1 2013, 14:51:22 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme Since I have a workaround (TortoiseSVN) is there anything I should be concerned about with this revision? Is this anomaly or artifact going to cause problems for us later with our current version of SVN? Is this anomaly or artifact going to cause problems for us later, when upgrading to a new version of SVN. How was this caused? Is there additional information (property/meta data) that can help pin-point the cause? Thanks much, take care, -Jim
Re: large db/revs files
On 2013-06-04 16:30, Andre Harper wrote: > Hi, all – > > I am not subscribed and would appreciate being explicitly Cc:ed in any > responses. > > I am on a team that began using subversion near the end of last year. > As a part of our process, we tag each successful run of our systems. > This can mean thousands of tags for certain systems every six months. > > We’re having an issue with the db/revs directory size, which for all > our projects currently exceeds 289G. We only use relatively small > working directories containing less than a meg of text files; no > binary files. > > In the archives, I found a mention that the db/revs directories are > populated using xdelta, but there didn’t appear to be a solution to > large file sizes at time > [http://svn.haxx.se/users/archive-2011-08/0229.shtml > ]. I was hoping someone may have found a work-around or solution. > > Would someone be able to: > 1)suggest how to avoid this in the future > 2)suggest how to reduce the current large files (if possible) > > Thank you. > André Harper > Wow, how many revisions are this and what is the average size of the source (1MB)? Even with a several thousands tags and plain text files there is a change to keep the repository small. For example your files could be plain text files with - max 10 chars per line (good for xdelta) - containing only single line (bad for xdelta) - EOL style / white spacing changed during commit (bad for xdelta) - With the worst case examples in mind you can inspect your sources and maybe find some improvements. Have you looked direct on the server side to the repo ($repo/db/), where is all the space used? - rep-cache.db - revs - transactions (I've seen repos with several GB inside) - revprops
RE: Tree conflict on Fresh checkout
> From: James Hanley [mailto:jhan...@dgtlrift.com] > Sent: Tuesday, June 04, 2013 1:44 PM > To: users@subversion.apache.org > Subject: Tree conflict on Fresh checkout > > We are seeing a strange anomaly after our last check-in - on fresh checkout > there is a tree conflict into a new path - I've included the output below. > > $ svn status > D C Project/settings/MkImage > > local unversioned, incoming add upon update > D Project/settings/MkImage/Makefile > D Project/settings/MkImage/defs.h > D Project/settings/MkImage/main.c > Summary of conflicts: > Tree conflicts: 1 Any chance it's a case issue, i.e. MkImage versus mkimage in the same dir? Do an 'svn ls Project/settings'. And are you using a Windows svn client in a cygwin bash shell, or the cygwin built svn client?
Re: Tree conflict on Fresh checkout
I can reproduce on the versions specified above of the CygWin svn client within CygWin, but I haven't tried the native windows svn client. Strange thing is that this is only an issue with MkImage, and MkSharedData... user_dude@computer_node ~/projects/my_project/my_project_03b_pristine $ svn ls -v Project/settings 2528 cm_user May 30 19:28 ./ ... 2528 cm_user May 30 19:28 MkBinFile/ 2528 cm_user May 30 19:28 MkImage/ 2528 cm_user64131 May 30 19:28 MkImage.exe 2528 cm_user May 30 19:28 MkSharedData/ 2528 cm_user59528 May 30 19:28 MkSharedData.exe ... 2209 cm_user 85 May 07 12:52 run.cmd user_dude@computer_node ~/projects/my_project/my_project_03b_pristine $ On Tue, Jun 4, 2013 at 2:22 PM, Andrew Reedick wrote: > > > > From: James Hanley [mailto:jhan...@dgtlrift.com] > > Sent: Tuesday, June 04, 2013 1:44 PM > > To: users@subversion.apache.org > > Subject: Tree conflict on Fresh checkout > > > > We are seeing a strange anomaly after our last check-in - on fresh > checkout there is a tree conflict into a new path - I've included the > output below. > > > > $ svn status > > D C Project/settings/MkImage > > > local unversioned, incoming add upon update > > D Project/settings/MkImage/Makefile > > D Project/settings/MkImage/defs.h > > D Project/settings/MkImage/main.c > > Summary of conflicts: > > Tree conflicts: 1 > > Any chance it's a case issue, i.e. MkImage versus mkimage in the same dir? > Do an 'svn ls Project/settings'. > > And are you using a Windows svn client in a cygwin bash shell, or the > cygwin built svn client? > > >
RE: Tree conflict on Fresh checkout
> From: James Hanley [mailto:jhan...@dgtlrift.com] > Sent: Tuesday, June 04, 2013 3:12 PM > To: Andrew Reedick > Cc: users@subversion.apache.org > Subject: Re: Tree conflict on Fresh checkout > > I can reproduce on the versions specified above of the CygWin svn client > within CygWin, but I haven't tried the native windows svn client. Strange > thing is that this is only an issue with MkImage, and MkSharedData... > > user_dude@computer_node ~/projects/my_project/my_project_03b_pristine > $ svn ls -v Project/settings >2528 cm_user May 30 19:28 ./ >... >2528 cm_user May 30 19:28 MkBinFile/ >2528 cm_user May 30 19:28 MkImage/ >2528 cm_user64131 May 30 19:28 MkImage.exe >2528 cm_user May 30 19:28 MkSharedData/ >2528 cm_user59528 May 30 19:28 MkSharedData.exe >... >2209 cm_user 85 May 07 12:52 run.cmd > > user_dude@computer_node ~/projects/my_project/my_project_03b_pristine > $ 'svn ls' sorts output and the sort is case sensitive. Since you truncated your output, we can't tell if you have a case sensitive filename problem. Run 'svn ls -v Project/settings | grep -i mkimage' to see if you have duplicate "mkimage" entries. Under 1.7.9, I get a tree conflict when I have "alpha" and "Alpha" in the same dir under Cygwin. $ svn ls -v svn://localhost/test/case 111 test Jun 04 15:18 ./ 111 test Jun 04 15:18 Alpha/ 110 test Jun 04 15:18 alpha/ $ svn co svn://localhost/test/case Acase/Alpha C case/alpha Checked out revision 111. $ svn status case D C case/alpha > local unversioned, incoming add upon update Summary of conflicts: Tree conflicts: 1 Finally, if you're using Outlook, when composing an email for the list, click Options -> Plain Text.
Re: authentication error after upgrading client to svn1.8.0-rc2 (accessing a svn1.7.8 server)
On 06/03/13 20:31, C. Michael Pilato wrote: On 05/31/2013 02:26 PM, C. Michael Pilato wrote: Filed an issue for this in the Serf tracker: https://code.google.com/p/serf/issues/detail?id=102 Just to follow up on this: the Serf devs have fixed the problem, and the fix will be included in Serf 1.2.1 (which should be released in the next couple of days). Thanks so much for your bug report!! After rebuilding with serf 1.2.1 i can confirm that my issue is solved. :-) Many thanks to the svn and serf team for this impressively quick solution. Klaus
答复: How to use SVN to setup CIMS
Dears I found that the tool of svnlook can cat the edit file with "-t" option in pre-commit script. I do this in the server side, can I do the same this in client side? Best regards LiberalJin -邮件原件- 发件人: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 发送时间: 2013年6月4日 13:03 收件人: Liberal Jin 抄送: users@subversion.apache.org 主题: Re: How to use SVN to setup CIMS On Jun 3, 2013, at 21:46, liberal...@viatech.com.cn wrote: > I want to set up a cims by SVN. I don't know what "cims" is, but… > The system need to do a series test before commit. This has been recently discussed, and the consensus was "don't do that", because there's no way for you to obtain a consistent state of the repository to test until the commit has been finalized. http://svn.haxx.se/users/archive-2013-05/0261.shtml Instead, use a continuous integration system that tests your build after each commit, and reports build failures (e.g. to a group email list) so that whoever committed a bad revision will know about it and can fix it quickly.
Re: How to use SVN to setup CIMS
On Jun 5, 2013, at 01:47, wrote: > I found that the tool of svnlook can cat the edit file with "-t" option in > pre-commit script. That's right, svnlook can look into transactions or revisions. > I do this in the server side, can I do the same this in client side? No; svnlook is the only tool that can look into transactions, and it only operates on local repositories, not over a network.
RE: Merging change sets for a production release,
Hi again - I have a follow up question, please. I had an helpdesk issue with 18 changesets attributed to it. It took a while to resolve all the issues - but I finally got there. I did a "diff" on one of the files and I noticed that in the revision that there was a conflict for that file - there was no mergeinfo recorded for that revision. Do I need to do a --record-only "post" merge when there is a conflict? As always - thanks, - Gavin. > -Original Message- > From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] > Sent: Tuesday, 4 June 2013 06:08 > To: Gavin Baumanis; users@subversion.apache.org > Subject: RE: Merging change sets for a production release, > > > > > -Original Message- > > From: Gavin Baumanis [mailto:gbauma...@cogstate.com] > > Sent: Monday, June 03, 2013 2:27 PM > > To: Andrew Reedick; users@subversion.apache.org > > Subject: RE: Merging change sets for a production release, > > > > Hi Andrew, > > Thanks for your response. > > > > I do everything but for the chaining of the revisions to merge in the > > same command. > > I tried it once (granted a long time ago) and it caused such an issue > > for me that after about 6 hours of swearing, I finally gave up and > > reverted the changes and did the merges one by one. > > At the time one by one allowed for individual merge conflicts - which > > made life a little easier. > > > > As for the other ideas, we do already only merge changes from trunk > > that are complete and have been given the appropriate release > > milestone. > > Our release process is already issue-based. > > > > Perhaps simply chaining the merge revisions is the answer? > > > > Yes, I would try the 'svn merge -c ...' "changed" merge again. > > Assuming you're using SVN 1.7, "chained" merges should be much easier. It > is still an iterative process, in that if a merge conflict is encountered, > svn will > prompt you for what to do, then you fix the code, resolve the conflict, and > re-run the merge command to pick up where it left off. You will probably > want to use 'svn merge --accept postpone ...' to avoid the prompting. It's > normally a good idea to save off your merge command so you can add it to > the commit comment (or in case anything happens to your command line's > history buffer.) >
