Tree conflicts on merging into a branch
Hello, I have seen an issue with subversion in which tree conflicts are being produced when creating a branch from a working copy in which not all files are at the same revision. This is happening when trying to merge changes into this branch. Please refer to the following sequence. Is this supposed to be happening in this way? I do not exactly understand what causes the tree conflicts. Shouldn't there at least be a warning on trying to copy from a working copy with mixed revisions? svn co https://localhost/svn/test Checked out revision 0. cd test testmkdir trunk testmkdir branches testmkdir tags testsvn add trunk branches tags A trunk A branches A tags testsvn commit -m initial structure Adding branches Adding tags Adding trunk Committed revision 1. testsvn switch https://localhost/svn/test/trunk Dtrunk Dbranches Dtags Updated to revision 1. testmkdir d1 testmkdir d2 testmkdir d3 testecho loremipsum d1\f1.txt testecho loremipsum d2\f1.txt testecho loremipsum d3\f1.txt testsvn add d1 d2 d3 A d1 A d1\f1.txt A d2 A d2\f1.txt A d3 A d3\f1.txt testsvn ci -m stuff Adding d1 Adding d1\f1.txt Adding d2 Adding d2\f1.txt Adding d3 Adding d3\f1.txt Transmitting file data ... Committed revision 2. testsvn copy . https://localhost/svn/test/branches/b1 -m created b1 Committed revision 3. testsvn rename d1 d1_r A d1_r D d1\f1.txt D d1 testsvn commit -m d1 renamed Deleting d1 Adding d1_r Committed revision 4. testsvn switch https://localhost/svn/test/branches/b1 Dd1_r Ad1 Ad1\f1.txt Updated to revision 4. testsvn merge https://localhost/svn/test/trunk --- Merging r2 through r4 into '.': Ad1_r Ad1_r\f1.txt C d2 C d3 Summary of conflicts: Tree conflicts: 2 D:\repositories\testsvn status -v M 43 weyh . 43 weyh d1 42 weyh d1\f1.txt C 43 weyh d2 local add, incoming add upon merge 42 weyh d2\f1.txt A + - ? ? d1_r A + -2 weyh d1_r\f1.txt C 43 weyh d3 local add, incoming add upon merge 42 weyh d3\f1.txt Best regards, Matthias
RE: Common name for transaction and revision object
If you look at the svn_fs.h API, they are both referred to as revision roots. svn_fs_revision_root() and svn_fs_txn_root() both return a svn_fs_root_t * object. That does not sound like they're both being referred to as revision roots; that sounds like they're both being referred to as roots. If you're just looking to name a variable, you can call it RevisionOrTransaction. I'm trying to name a class that will hold information about a transaction (during pre-commit) or a revision (during post-commit). Because the information is pretty much the same, e.g path, url, files changes, log message, etc., I thought I could have a common class and then either use it in both pre- and post-commit hooks or use it as a parent class of more specialised Transaction and. Revision classes. I'm working in Perl, btw. I'm leaning towards calling it TxnRev to be honest. G Linedata Services (UK) Ltd Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB Registered in England and Wales No 3027851VAT Reg No 778499447
Cherry-picking merges
Hi, I know, this is maybe not the best practice, but, unfortunately, our subversion users do this all the time: they merge form one branch to another back and forward. The question is, how to properly do it without introducing conflicts. Here is the test case, which one would think should be handled properly, but for some reason it's not: [~]$ svnadmin create mergerepo [~]$ svn co file://`pwd`/mergerepo mergework Checked out revision 0. [mergework]$ svn mkdir --parents branches/b1 A /home/vvc/mergework/branches A /home/vvc/mergework/branches/b1 [mergework]$ svn commit -m Created branch b1 Adding branches Adding branches/b1 Committed revision 1. [mergework]$ svn copy branches/b1 branches/b2 A branches/b2 [mergework]$ svn commit -m Created branch b2 Adding branches/b2 Committed revision 2. [b2]$ touch README [b2]$ svn add README A README [b2]$ svn commit -m Added README Adding b2/README Transmitting file data . Committed revision 3. [b1]$ svn merge -c 3 ^/branches/b2 --- Merging r3 into '.': AREADME [b1]$ svn commit -m Merged r3 into b1 Sendingb1 Adding b1/README Committed revision 4. [b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 Thanks, Sincerely, Vadym Chepkov
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 10:08 AM, Vadym Chepkov vchep...@gmail.com wrote: Hi, I know, this is maybe not the best practice, but, unfortunately, our subversion users do this all the time: they merge form one branch to another back and forward. The question is, how to properly do it without introducing conflicts. Here is the test case, which one would think should be handled properly, but for some reason it's not: [~]$ svnadmin create mergerepo [~]$ svn co file://`pwd`/mergerepo mergework Checked out revision 0. [mergework]$ svn mkdir --parents branches/b1 A /home/vvc/mergework/branches A /home/vvc/mergework/branches/b1 [mergework]$ svn commit -m Created branch b1 Adding branches Adding branches/b1 Committed revision 1. [mergework]$ svn copy branches/b1 branches/b2 A branches/b2 [mergework]$ svn commit -m Created branch b2 Adding branches/b2 Committed revision 2. [b2]$ touch README [b2]$ svn add README A README [b2]$ svn commit -m Added README Adding b2/README Transmitting file data . Committed revision 3. [b1]$ svn merge -c 3 ^/branches/b2 --- Merging r3 into '.': AREADME [b1]$ svn commit -m Merged r3 into b1 Sendingb1 Adding b1/README Committed revision 4. [b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 After r3, you'll need to do a '--record-only' merge of r4 into the second branch: (untested) svn merge --record-only -c 4 ^/branches/b1 SVN doesn't seem to trace back through the commits to see that r3 was really a merge from b2-b1. Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). Cheers, Daniel B.
Re: Cherry-picking merges
Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). I would be interested in knowing this very good reason why it can't. I'm not questioning its validity, I'm confident this good reason is a good reason, but as I was surprised too by this behavior, if someone could give an explanation? I would be very interested. Joël
SVN tags
Hello, I have a query. How to find tag(s) associated with any file available in trunk? For example cvs stat shows the list of tags associated with any file. Can something like this be done in SVN? Best, Hemant Unstoppable..
Re: SVN tags
On Thu, Apr 29, 2010 at 2:08 PM, Wadhavankar, Hemant hemant.wadhavan...@lsi.com wrote: Hello, I have a query. How to find tag(s) associated with any file available in trunk? For example “cvs stat” shows the list of tags associated with any file. Can something like this be done in SVN? First of all Subversion is not CVS, files are not tagged in Subversion. Best, Hemant *Unstoppable..* -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
How to allow anonymous access, but not everyone access in path-based authorization?
I have a subversion server running with apache. It authenticates users using LDAP configuration and uses SVN path-based authorizations to limit user access to certain repositories. This works perfectly. Now, I have a service I want to setup (rietveld, for code reviews) that needs to have an anonymous access to the repository. As this is a web service, accesses are always done from the same server. Thus I added an apache configuration to allow accesses from this machine. without user authentication. |Limit GET PROPFIND OPTIONS REPORT Order allow,deny Allow from # private IP address Satisfy Any /Limit | This did not work until I add an additional line * = r in the authorization file to allow read access to all users. For instance, before I add the authorization from a specific IP, all users were authenticated, and thus had a name. Now, some accesses are done without a user name! I found the |-| user name in the apache log files, but the line |- = r| does not work, neither do |anonymous = r|. I'd like not to allow read access to everyone in SVN authorization. How can I do this? (More details in stackoverflow question http://stackoverflow.com/questions/2728021/how-to-allow-unamed-user-in-svn-authz-file
Re: How to allow anonymous access, but not everyone access in path-based authorization?
On Thu, Apr 29, 2010 at 3:09 PM, Didier Trosset didier_tros...@agilent.comwrote: I have a subversion server running with apache. It authenticates users using LDAP configuration and uses SVN path-based authorizations to limit user access to certain repositories. This works perfectly. Now, I have a service I want to setup (rietveld, for code reviews) that needs to have an anonymous access to the repository. As this is a web service, accesses are always done from the same server. Thus I added an apache configuration to allow accesses from this machine. without user authentication. |Limit GET PROPFIND OPTIONS REPORT Order allow,deny Allow from # private IP address Satisfy Any /Limit | This did not work until I add an additional line * = r in the authorization file to allow read access to all users. For instance, before I add the authorization from a specific IP, all users were authenticated, and thus had a name. Now, some accesses are done without a user name! I found the |-| user name in the apache log files, but the line |- = r| does not work, neither do |anonymous = r|. I'd like not to allow read access to everyone in SVN authorization. How can I do this? (More details in stackoverflow question http://stackoverflow.com/questions/2728021/how-to-allow-unamed-user-in-svn-authz-file IMHO there is no way to do it other than creating a dummy user and giving it access to all repositories in authorization file as we had similar issues integrating Subversion repositories with JIRA. -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
Re: How to allow anonymous access, but not everyone access in path-based authorization?
On Thu, Apr 29, 2010 at 11:53 AM, vishwajeet singh dextrou...@gmail.com wrote: On Thu, Apr 29, 2010 at 3:09 PM, Didier Trosset didier_tros...@agilent.com wrote: I have a subversion server running with apache. It authenticates users using LDAP configuration and uses SVN path-based authorizations to limit user access to certain repositories. This works perfectly. Now, I have a service I want to setup (rietveld, for code reviews) that needs to have an anonymous access to the repository. As this is a web service, accesses are always done from the same server. Thus I added an apache configuration to allow accesses from this machine. without user authentication. | Limit GET PROPFIND OPTIONS REPORT Order allow,deny Allow from # private IP address Satisfy Any /Limit | This did not work until I add an additional line * = r in the authorization file to allow read access to all users. For instance, before I add the authorization from a specific IP, all users were authenticated, and thus had a name. Now, some accesses are done without a user name! I found the |-| user name in the apache log files, but the line |- = r| does not work, neither do |anonymous = r|. I'd like not to allow read access to everyone in SVN authorization. How can I do this? (More details in stackoverflow question http://stackoverflow.com/questions/2728021/how-to-allow-unamed-user-in-svn-authz-file IMHO there is no way to do it other than creating a dummy user and giving it access to all repositories in authorization file as we had similar issues integrating Subversion repositories with JIRA. You can do this if you set up a separate Location block (referring to the same svn repo) for this anonymous access. Then they can each have their own authz file (or no authz file if it's not needed). I don't see another way. We do something like that: Location /svn DAV svn SVNPath /path/to/repos ... auth possible authz stuff /Location Location /svn_anon DAV svn SVNPath /path/to/repos ... auth authz stuff, Limit, ... for anonymous access within certain limits /Location Cheers, -- Johan
Re: SVN tags
On Thu, Apr 29, 2010 at 12:08 PM, Andy Levy andy.l...@gmail.com wrote: On Thu, Apr 29, 2010 at 04:38, Wadhavankar, Hemant hemant.wadhavan...@lsi.com wrote: Hello, I have a query. How to find tag(s) associated with any file available in trunk? For example “cvs stat” shows the list of tags associated with any file. Can something like this be done in SVN? It can't. In SVN, tags are not properties of files. It's the other way around, conceptually. SVN is not CVS - you will have to do some things differently and change your way of thinking. Fortunately, The Book has a whole section just for people who need help with the transition. http://svnbook.red-bean.com/nightly/en/svn.forcvs.html That said, I really miss this feature too (the ability to see at a glance all the branches/tags/... a certain revision was copied to, f.i. when looking at the log of a file). It's true that this is not possible with SVN currently, because the repository doesn't keep track of copy_to information (where was this file copied to), only copy_from information (where was this file copied from). So you can only calculate the copy_to information by analyzing the entire history of the repository, and deduce this info (some clients and third-party software do this stuff, to create revision graphs and such (e.g. TortoiseSVN)). Full support for this kind of question will have to wait for major changes to the SVN back-end filesystem, so it keeps track of the copy_to information. Maybe it's something that will be considered for FS-NG in the not-so-near future (see http://subversion.apache.org/roadmap.html and take a look at the most wanted features, where it says Forward history searching). However, the following question can still be answered easily with current SVN: Given tag X, which revision of file Y was included? Very often the above general question (which tags was this (version of a) file copied to?) can be rephrased to a question about a specific tag (e.g. you want to know if your bugfix is included in a certain release (tag X) or not). Cheers, -- Johan
Re: Cherry-picking merges
On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote: [b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 After r3, you'll need to do a '--record-only' merge of r4 into the second branch: (untested) svn merge --record-only -c 4 ^/branches/b1 SVN doesn't seem to trace back through the commits to see that r3 was really a merge from b2-b1. Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). Cheers, Daniel B. Well, as you can see in the log, it also wants to merge r3 back, not just r4, so we would have to record-only 2 of them, it seems. The problem is, we utilize a home made automerge utility that constantly merges all changes from b1 to b2, but merges from b2 to b1 are done manually. After r4 is committed, it produces conflict for automerge immediately and this is what I am trying to avoid. By the way, maybe there is an intelligent automerge utility out there that can handle this kind of things, if anyone knows. Thanks, Vadym
Re: Help importing apache settings.
On Thursday 29 Apr 2010, j_dorocak wrote: Dear SVN folks, I am trying to import the current status of my apache2 server directory structure into a repository. I get cut off after 2 successes: Adding /home/jdor/webapps/pinax07server/apache2/logs Adding /home/jdor/webapps/pinax07server/apache2/logs/PrivateDoor_2009_05_06.log svn: Unknown or unversionable type for '/home/jdor/webapps/pinax07server/apache2/logs/wsgi.11484.0.1.sock' Are there any switches that will tell svn import to keep going, and just skip over that which is unversionable? Thanks in advance. Joe Joe Dorocak email: j_doro...@comcast.net You can use the svn:ignore property to avoid adding certain files or directories. This is a property set on directories or globally in the config file, in your case I'd put it on the apache2 directory unless you feel you need to version log files? For example, in the directory /home/jdor/webapps/pinax07server/apache2 run the command svn propset svn:ignore logs . although, like me, you may prefer to use the propedit command without the logs parameter as I find it easier when adding multiple entries. All of this assumes you are adding to a working copy rather than importing. I think you'll need to add entries to the config file if you want to do it from a svn import. The redbook page http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.ignore.html covers the ignoring files in much more detail, including how to do it from the configuration files. To me there isn't a big difference between adding and importing. All you need to do for adding to a working copy is create an empty one and copy across the apache directory. Then you can use the working copy commands to configure exactly how you would like the files to be versioned without having to cleanup mistakenly committed files such as the text log files. Campbell -- __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __
RE: Doubts - SVN.
Take a look at the website [1], there you will find the binary packages [2] and a link to one of the manuals [3]. [1] http://subversion.apache.org [2] http://subversion.apache.org/packages.html [3] http://svnbook.red-bean.com/ . . . . I work at a company that is considering the use of SVN. I would like your help to understand what are the terms of this license? How can I purchase it and how is the installation procedure? It is compatible with Windows Vista? Barbara, your questions are actually complicated ones to answer, especially your question about Vista compatibility. Are you asking about supporting users who work on Vista machines? Running an SVN server on Vista? There's more to this decision than a simple yes or no answer. There are several SVN client tools that are not part of Subversion itself but which are commonly used. Finally, many users integrate SVN with other tools for project tracking, etc. The Subversion Book, which you can get from Nick's third link, explains the issues in good detail. I'd start there to understand what you can do with Subversion. Erik
How does one get mod_dav_svn.so ?
Dear All, I am a complete new comer to Subversion and our project is about to take it on. As a version control system. I am initially inpressed by it and am now trying to get it to work via a browser. I want to include mod_dav_svn.so in the httpd.conf file but mod_dav_svn.so does not exist in my installation. I am installing on HP-UX 11.31 Itanium Here is what I have done so far. Downloaded and installed all utilities apr, apr_util, etc. Downloaded and installed Apache 2.2.15 with depot file apache2-2.2.15-ia64-11.31.depot - it works fine. Downloaded and installed Subversion with depot file subversion-1.6.11-ia64-11.31.depot It looks good svn --version svn, version 1.6.11 (r934486) compiled Apr 21 2010, 14:20:00 Now I want to add this to the http.conf LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so But I don't have mod_dav_svn.so in the apache modules file r...@rise-01 cd /usr/local/apache2 r...@rise-01 find . -name mod_dav* ./include/mod_dav.h ./lib/modules/mod_dav.so ./lib/modules/mod_dav_fs.so The install manual states Subversion, and the mod_dav_svn filesystem provider module distributed with Subversion. Distributed how? Am I missing something? Regards, Rob Ferguson This e-mail and any attachments hereto are: # strictly confidential and intended solely for the addressee. If you are not the intended addressee, you must not disclose, forward, copy, or take any action in reliance on this e-mail or attachments. If you have received this e-mail in error, please notify the NHS Supply Chain sender rob.fergu...@supplychain.nhs.uk as soon as possible. # not intended to create contractual relations or legally binding obligations binding on NHS Supply Chain and no action may be taken in reliance on this e-mail and any attachments hereto unless the contents are confirmed by letter. # Addressees should check all attachments for viruses. NHS Supply Chain makes no representations are made as regards the absence of viruses in attachments to this e-mail.
repo size discrepency when loading from dump
I have an issue with subversion dumps (RHEL 5.2; subversion 1.5.0; viewvc 1.0.7) when I'm trying to load onto a new server (CentOS 5.4; subversion 1.6.11; viewvc 1.0.11). On disk, the size of the folder for one of the repositories is 1.3gb. When I do a dump, the file size is 1.3gb. However, when I load on the new server, it finishes with no errors but the size is 440mb. I tried the same thing with another repository with the same results. The initial size is just over 2gb but after loading on the new box, it is only 1.3gb Are there differences in the new version that is essentially normal behavior to see this size reduction? Seth Simmons Systems Administrator Cymfony Office: 617.673.6024 Fax: 617.924.6167 www.cymfony.com smime.p7s Description: S/MIME cryptographic signature
Re: repo size discrepency when loading from dump
On Thu, Apr 29, 2010 at 10:34 PM, Seth Simmons ssimm...@cymfony.com wrote: I have an issue with subversion dumps (RHEL 5.2; subversion 1.5.0; viewvc 1.0.7) when I’m trying to load onto a new server (CentOS 5.4; subversion 1.6.11; viewvc 1.0.11). On disk, the size of the folder for one of the repositories is 1.3gb. When I do a dump, the file size is 1.3gb. However, when I load on the new server, it finishes with no errors but the size is 440mb. I tried the same thing with another repository with the same results. The initial size is just over 2gb but after loading on the new box, it is only 1.3gb Are there differences in the new version that is essentially normal behavior to see this size reduction? Did you performed some sanity checks to your data like looking at history, I really don't see any issue if dump completed successfully there were many Filesystem storage improvements in Subversion 1.6 size reduction may be due to that. http://subversion.apache.org/docs/release-notes/1.6.html#filesystem-improvements Seth Simmons Systems Administrator *Cymfony* Office: 617.673.6024 Fax: 617.924.6167 www.cymfony.com -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
Re: Cherry-picking merges
[b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 and yet another strange thing about it. There is no way to automatically resolve a conflict like this. no matter what flag I use --accept mine-conflict, mine-full, nothing seems to make merge operation happy. I have to issue a separate svn resolve --accept working command afterwards. Vadym
Free Online Subversion Training - Introduction to Subversion for Developers
The second course in the series, Introduction to Subversion for Developers will take place on Wednesday, May 5, 2010 at 9AM PDT. Subversion's architecture and design principles will be covered and attendees will be introduced to using Subversion for software development. http://wandisco.com/webinar/subversion/training
RE: repo size discrepency when loading from dump
Yes that seems to be the difference. I had one of my developers check one repository that was much smaller on the new server and the current revision matches. From: vishwajeet singh [mailto:dextrou...@gmail.com] Sent: Thursday, April 29, 2010 1:13 PM To: Seth Simmons Cc: users@subversion.apache.org Subject: Re: repo size discrepency when loading from dump On Thu, Apr 29, 2010 at 10:34 PM, Seth Simmons ssimm...@cymfony.com wrote: I have an issue with subversion dumps (RHEL 5.2; subversion 1.5.0; viewvc 1.0.7) when I'm trying to load onto a new server (CentOS 5.4; subversion 1.6.11; viewvc 1.0.11). On disk, the size of the folder for one of the repositories is 1.3gb. When I do a dump, the file size is 1.3gb. However, when I load on the new server, it finishes with no errors but the size is 440mb. I tried the same thing with another repository with the same results. The initial size is just over 2gb but after loading on the new box, it is only 1.3gb Are there differences in the new version that is essentially normal behavior to see this size reduction? Did you performed some sanity checks to your data like looking at history, I really don't see any issue if dump completed successfully there were many Filesystem storage improvements in Subversion 1.6 size reduction may be due to that. http://subversion.apache.org/docs/release-notes/1.6.html#filesystem-improvem ents Seth Simmons Systems Administrator Cymfony Office: 617.673.6024 Fax: 617.924.6167 www.cymfony.com -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet smime.p7s Description: S/MIME cryptographic signature
Copying from one repository to another, flattening the early part of the source repo's history in the target repo?
I'm working on some Subversion-related software for propagating trunk checkins to any of dozens of target branches, based on trunk's checkin comments (that is, where the checkins need to subsequently go automatically is determined by the checkin comments in trunk, and those comments are prepared pretty consistently by a custom GUI; the GUI piece is already written and in production). I of course want it to work well when we deploy it - and the trunk we'll ultimately be running it against is rather huge. So to make it work well from the start, I need to test it well. To test it, I really want to copy from one SVN server's trunk to another SVN server's repository - flattening a significant part of the early history from the source trunk, and then having as-identical-as-practical checkin comments for the later history. Is there already a way of setting up such a test branch? I've googled about it quite a bit and come up with things that are close (svnsync: way too much test data, svn merge: too few checkin comments unless I do them individually somehow), but not quite what I need. It's seeming like writing the program to prepare the test environment is nearly as complex as what I'm intending to test. Please note that although I've been an SVN admin in the past, I do not have administrative access to these SVN servers. TIA! (PS: I've written a bunch of unit tests for this, but that's just not enough - it needs to be tested as a complete system too with minimal deviation from how it's to be used In Real Life)
Re: Copying from one repository to another, flattening the early part of the source repo's history in the target repo?
On Thu, Apr 29, 2010 at 11:23 AM, Les Mikesell lesmikes...@gmail.com wrote: On 4/29/2010 1:06 PM, Dan Stromberg wrote: I'm working on some Subversion-related software for propagating trunk checkins to any of dozens of target branches, based on trunk's checkin comments (that is, where the checkins need to subsequently go automatically is determined by the checkin comments in trunk, and those comments are prepared pretty consistently by a custom GUI; the GUI piece is already written and in production). I of course want it to work well when we deploy it - and the trunk we'll ultimately be running it against is rather huge. So to make it work well from the start, I need to test it well. To test it, I really want to copy from one SVN server's trunk to another SVN server's repository - flattening a significant part of the early history from the source trunk, and then having as-identical-as-practical checkin comments for the later history. I don't understand the need to flatten the trunk. Fanning out from the trunk to many branches should be straightforward enough, fhough. The source branch is terabytes of source code. I want to restrict by subdirectory, and flatten history to reduce the storage requirements. As far as straightforward enough, yes, it's conceptually simple enough, though I've got 600+ lines of Python code written for this so far (not including unit tests or test inputs), and it's not done yet. It includes XML parsing, YAML parsing, SVN interaction (with error checking), a flat file database module (because the customer doesn't want to use gdbm or similar), etc. Is there already a way of setting up such a test branch? I've googled about it quite a bit and come up with things that are close (svnsync: way too much test data, svn merge: too few checkin comments unless I do them individually somehow), but not quite what I need. It's seeming like writing the program to prepare the test environment is nearly as complex as what I'm intending to test. Please note that although I've been an SVN admin in the past, I do not have administrative access to these SVN servers. The only way you can modify existing history is with a svnadmin dump/filter/load and you need admin access for that. Can you svnsync the live repo to one you control, then dump from there to get a base for your test? I guess I'm not entirely looking to modify existing history, so much as compress the old stuff by flattening and restricting it, and then cloning the recent history. I can imagine a program to do this (at least to an extent) that doesn't require admin access, but I'm hoping someone's already written it. It's starting to sound like I'm going to need to write a bash script to handle this.
Can we use relative paths in svn:externals propset?
I have two projects under a single repository, with A being dependent on B being checked out. To set the svn:externals propset, can I use a relative path for the checkout directory for the depending (B) directory? Such as : svn propset svn:externals ../buildsupport http://URL/buildsupport/trunk BuildScripts Will this work? I can't afford to try it on that repository since it's a live development repository... Thanks! -- Dingo Dave Bartmess Broomfield, CO. USA http://edingo.net
Re: Can we use relative paths in svn:externals propset?
On 04/29/2010 01:09 PM, David Bartmess wrote: I have two projects under a single repository, with A being dependent on B being checked out. To set the svn:externals propset, can I use a relative path for the checkout directory for the depending (B) directory? Such as : svn propset svn:externals ../buildsupport http://URL/buildsupport/trunk BuildScripts Will this work? I can't afford to try it on that repository since it's a live development repository... You can always try setting up externals by modifying them in your working copy and running svn update and see if you get the desired result. You don't need to commit the change to test it. IIRC, you can't have a relative path to a directory outside the directory where the external is, as it doesn't know if it's a Subversion working copy or not. Blair
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 9:17 PM, Vadym Chepkov vchep...@gmail.com wrote: On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote: [b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 After r3, you'll need to do a '--record-only' merge of r4 into the second branch: (untested) svn merge --record-only -c 4 ^/branches/b1 SVN doesn't seem to trace back through the commits to see that r3 was really a merge from b2-b1. Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). Cheers, Daniel B. Well, as you can see in the log, it also wants to merge r3 back, not just r4, so we would have to record-only 2 of them, it seems. I'm pretty sure that you only need to do a record-only of r4. If you do a 'svn merge -r 2:3 ^/branches/b1, I don't think it will actually do anything (other than modify the mergeinfo property). When I get a chance, I'll run a quick test on it (or if you have the WCs from the above example, you could try it yourself). The problem is, we utilize a home made automerge utility that constantly merges all changes from b1 to b2, but merges from b2 to b1 are done manually. After r4 is committed, it produces conflict for automerge immediately and this is what I am trying to avoid. By the way, maybe there is an intelligent automerge utility out there that can handle this kind of things, if anyone knows. You could check if r4 contains mergeinfo for b2, and if so, don't worry about doing the merge between b1-b2, or force it to be record-only. Cheers, Daniel B.
Re: Can we use relative paths in svn:externals propset?
David Bartmess wrote: I have two projects under a single repository, with A being dependent on B being checked out. To set the svn:externals propset, can I use a relative path for the checkout directory for the depending (B) directory? Such as : svn propset svn:externals ../buildsupport http://URL/buildsupport/trunk BuildScripts Will this work? I can't afford to try it on that repository since it's a live development repository... Maybe you can afford to read the manual, it explains all this...
Re: Can we use relative paths in svn:externals propset?
On 4/29/2010 2:18 PM, Blair Zajac wrote: On 04/29/2010 01:09 PM, David Bartmess wrote: I have two projects under a single repository, with A being dependent on B being checked out. To set the svn:externals propset, can I use a relative path for the checkout directory for the depending (B) directory? Such as : svn propset svn:externals ../buildsupport http://URL/buildsupport/trunk BuildScripts Will this work? I can't afford to try it on that repository since it's a live development repository... You can always try setting up externals by modifying them in your working copy and running svn update and see if you get the desired result. You don't need to commit the change to test it. IIRC, you can't have a relative path to a directory outside the directory where the external is, as it doesn't know if it's a Subversion working copy or not. Blair Thanks, that explains what I needed to know... Relative paths using a parent (..) or absolute paths aren't handled. So it won't work with my system, since all the build files point to a parent sandbox directory, not the current directory, for the dependencies... -- Dingo Dave Bartmess Broomfield, CO. USA http://edingo.net
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud jconr...@gmail.com wrote: Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). I would be interested in knowing this very good reason why it can't. I'm not questioning its validity, I'm confident this good reason is a good reason, but as I was surprised too by this behavior, if someone could give an explanation? I would be very interested. After thinking more about it, I believe it's because a revision can contain more than just the merge. For example, if I merge r10 from into a branch, I don't have to commit just that merge. I can have modifications in my working copy, merge, make more modifications, and commit in r11. The svn:mergeinfo will attest that r10 from trunk has been merged in this revision, but it doesn't mean that r11 on the branch is the logical equivalent of r10 on the trunk. I think that best practices suggest that doing things in this manner is a bad idea, and should be discouraged. A revision that contains svn:mergeinfo changes should only contain the file and structure changes logically equivalent to the revisions that have been merged. Cheers, Daniel B.
