Re: vendor branch merge: how to highlight patches for review?
On Wed, Aug 29, 2012 at 7:51 AM, Ryan Schmidt subversion-20...@ryandesign.com wrote: On Aug 28, 2012, at 17:56, Q. Chap quitec...@gmx.com wrote: What command(s) should I use to bring in the libcomplex/2.0 changes but identify the all files I ever messed with? These are two separate operations. [snip] $ svn merge ^/vendor/libcomplex/1.0 \ ^/vendor/libcomplex/2.0 \ libcomplex [snip] And then subsequently modified your copy in calc in some way and committed those changes, you can see which files you changed using this command: $ svn diff --summarize \ http://svn.example.com/repos/vendor/libcomplex/1.0 \ http://svn.example.com/repos/calc/libcomplex Thank you for the help. It's that last diff command that comes too late for my taste, though. You can run the diff command at any time that's convenient for you. As I wrote it above, it shows the changes between version 1.0 of the vendor code and the version of the vendor code committed to the calc project in the repository. I'd like to avoid checking in the libcomplex/2.0-project merge before doing a review. Sure. In fact, as I wrote it above, the command would not give correct output if you had already committed the merge. If you had committed the merge already, then you'd want to compare the original 2.0 code (not the original 1.0 code) with your code. Ideally, after the merge (but before commit) I'd like to be able to run a command like: svn diff --show-patches-to-vendor-code Output: list of lib files that I've changed at any point since the previous vendor drop. Could I do something like diff the (pre commit) project working copy against ^/vendor/libcomplex/2.0? Yes that sounds fine. Something like: $ svn diff --summarize \ http://svn.example.com/repos/vendor/libcomplex/1.0 \ path/to/workingcopyofcalc/libcomplex I think that last command needs the 2nd form of 'svn diff' syntax, because you're comparing an (arbitrary) url with a working copy path: [[[ diff (di): Display the differences between two revisions or paths. usage: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...] 2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \ [PATH...] 3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV] ]]] So that would be: $ svn diff --summarize \ --old=http://svn.example.com/repos/vendor/libcomplex/1.0 \ --new=path/to/workingcopyofcalc/libcomplex -- Johan
AW: Could not read chunk size. Secure connection truncated SVN Repo are getting corrupt
Hi, Goel, Von: Goel, Kapil [mailto:kapil.g...@fiserv.com] Stripping is alternative, but how repair the corrupted revision or what is the root cause to further stop corruption in other repos? Repository corruption is very unusual in Subversion. The most likely causes are: - The repository is running on a network file system or similar storage which does not properly implement synchronization / locking. - Hardware defect (defective RAM in the server, flipping bits on the cable). Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RE: Could not read chunk size. Secure connection truncated SVN Repo are getting corrupt
Hi Markus How we will identify Hardware issue , as diagnostics run by HW vendor didn't reported any issue on Hardware. Repos are on Dedicated server hardware of Dell Poweredge R710 Kapil Goel Deputy Manager - Systems Fiserv Global Services Fiserv Phone: +91-4023000 Fax No: +91-120-4023001 www.fiserv.com Please think of the environment before printing this e-mail. -Original Message- From: Markus Schaber [mailto:m.scha...@3s-software.com] Sent: Wednesday, August 29, 2012 1:18 PM To: Goel, Kapil; vishwajeet singh Cc: users@subversion.apache.org Subject: AW: Could not read chunk size. Secure connection truncated SVN Repo are getting corrupt Hi, Goel, Von: Goel, Kapil [mailto:kapil.g...@fiserv.com] Stripping is alternative, but how repair the corrupted revision or what is the root cause to further stop corruption in other repos? Repository corruption is very unusual in Subversion. The most likely causes are: - The repository is running on a network file system or similar storage which does not properly implement synchronization / locking. - Hardware defect (defective RAM in the server, flipping bits on the cable). Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Svn 1.7 merge info property
Am 29.08.2012 00:32, schrieb Rp0013: I wanted to mute the svn merge info property on my subversion server Is there such a way You could set up a pre-commit hook that makes sure that this property isn't touched in commits. We don't need the info currently and when merging it is causing a huge log with all changes to property being recorded and what we need is only the code merge Actually, there should be just a single directory (the root directory of the project) which receives this property. This assumes that you always merged from and to that directory, otherwise elements underneath that directory can also receive their own and distinct mergeinfo property, which they will also retain over future merges. I'd suggest this: 1. Educate your users that for proper merge tracking, they should always use the root directory as source and target even if the changes are only in a subdirectory thereof. 2. Delete the mergeinfo property from all non-root files and directories. 3. Optionally set up a pre-commit hook that verifies that only root directories receive the merge info. The result is that you have proper merge tracking (sorry, you say you don't want that, but it's hard for me to imagine that) but the only place where it is recorded is the root of your project. I'd hope that that could make everyone happy. Greetings from Hamburg! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: Could not read chunk size. Secure connection truncated SVN Repo are getting corrupt
Guten Tag Goel, Kapil, am Mittwoch, 29. August 2012 um 09:51 schrieben Sie: How we will identify Hardware issue , as diagnostics run by HW vendor didn't reported any issue on Hardware. If you're hardware looks ok, they still may be some problems with things like the filesystem of the OS hosting your repos. Last year I for example had a problem with a virtualized Windows 2003 R2 which suddenly got corrupted filesystems after years of running without any problems and no powerloss er else in the last weeks. The repos got corrupted, I restored them from a backup and some days later the same problem occured again. This time I restored to a newly created filesystem and again the repos run fine for months now. This may be an option for you, as all my other services on the same server ran fine, too. 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.030-2 1001-310 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
AW: Could not read chunk size. Secure connection truncated SVN Repo are getting corrupt
Hi, Goel, Von: Goel, Kapil [mailto:kapil.g...@fiserv.com] Stripping is alternative, but how repair the corrupted revision or what is the root cause to further stop corruption in other repos? Repository corruption is very unusual in Subversion. The most likely causes are: - The repository is running on a network file system or similar storage which does not properly implement synchronization / locking. - Hardware defect (defective RAM in the server, flipping bits on the cable). How we will identify Hardware issue , as diagnostics run by HW vendor didn't reported any issue on Hardware. Repos are on Dedicated server hardware of Dell Poweredge R710 It depends on your BIOS/Firmware and the OS. The first thing you should ensure is that you use Memory with ECC enabled. In the system management interface, there should be some log showing you about ECC corrected errors (or similar) - if this number is greater than 0, your memory is defect. Also, you could run tools like memtest86 - they find most memory errors which are not found by the POST. Of course, checking the SMART data for the hard disks is on the list, too. And I remember that some of the earlier SSDs shipped with borked firmware leading to data loss. However, I'm not the specialist for finding hardware defects (our sysadmins take care for that), and this is not the best place to find answers for that subject. Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RE: svn merge help
Nevermind. It was a simple mistake. I just had the revision numbers wrong, and it was (correctly) not merging any code from revisions before the branch. - Doug From: Douglass Davis [mailto:dda...@northcarolina.edu] Sent: Tuesday, August 28, 2012 3:55 PM To: users@subversion.apache.org Subject: svn merge help Hi, Client is svn, version 1.6.11 (r934486) I read the manual, but I'm not sure what I'm doing wrong. I copied https://mydomain/services/trunk (services) to https://mydomain/online/trunk (online) at revision 9884. There were several bugfixes made on services that I wanted to put in online. Some I just edited the code manually in my working copy of online. Right now, what I would like to do is just take the changes from revisions 9938 up to and including 9995 (about 20 revisions) from services (https://mydomain/services/trunk), and apply those to online (https://mydomain/online/trunk). So, I go to my working copy of online. I have tried this: svn merge -r 9937:9996 https://mydomain/services/trunk . And that just gives me the changes from revision 9995 of services. I revert, then tried svn merge https://svn.northcarolina.edu/os/cms/apps/services/trunk@9937 https://svn.northcarolina.edu/os/cms/apps/services/trunk@9995 . And still it only gave me the changes from 9995. How do I get all changes from 9937-9995 (inclusive) and apply them to my working copy of online? Thanks, Doug
Backwards compatible clients?
Are you of you guys aware of any SVN clients for Windows that will support 1.7 and 1.6 working copies? I need to update a load of clients to 1.7, but have some shared working copies and it would be useful to use the same client to access both working copy formats. Thanks *bypass*
Re: Backwards compatible clients?
On Wed, Aug 29, 2012 at 3:31 PM, Chris Evans chris.ev...@gresearch.co.uk wrote: Are you of you guys aware of any SVN clients for Windows that will support 1.7 and 1.6 working copies? I need to update a load of clients to 1.7, but have some shared working copies and it would be useful to use the same client to access both working copy formats. The only one I know that can do this is svnkit, the pure-Java (re)implementation of svn. It has a wrapper script that emulates the svn commandline (jsvn.bat, or jsvn.sh, or ..., depending on your environment). The latest version of svnkit (1.7.5-v1 at this time) supports working copy formats from 1.3 until 1.7. See www.svnkit.com. -- Johan
Re: Backwards compatible clients?
On Wed, Aug 29, 2012 at 02:31:47PM +0100, Chris Evans wrote: Are you of you guys aware of any SVN clients for Windows that will support 1.7 and 1.6 working copies? I need to update a load of clients to 1.7, but have some shared working copies and it would be useful to use the same client to access both working copy formats. Thanks AFAIK clients based on SVNKit 1.7 support this.
Compilation errors building subversion 1.7.6: missing headers
Building from tarballs on SUSE 11.1. I thought I had all the necessary dependencies, but I get this error message: /bin/sh /tc_work/fleck/subversion-1.7.6/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -Werror=implicit-function-declaration -I./subversion/include -I./subversion -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 -I/tc_work/fleck/subversion-1.7.6/sqlite-amalgamation -o tools/server-side/mod_dontdothat/mod_dontdothat.lo -c tools/server-side/mod_dontdothat/mod_dontdothat.c tools/server-side/mod_dontdothat/mod_dontdothat.c:25:19: error: httpd.h: No such file or directory tools/server-side/mod_dontdothat/mod_dontdothat.c:26:25: error: http_config.h: No such file or directory (plus many more) ...so obviously I need some Apache headers. What tarball(s) do I need to obtain and install to provide the needed headers? Thanks-
Re: Compilation errors building subversion 1.7.6: missing headers
David Fleck dcfl...@gmail.com writes: Building from tarballs on SUSE 11.1. I thought I had all the necessary dependencies, but I get this error message: /bin/sh /tc_work/fleck/subversion-1.7.6/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -Werror=implicit-function-declaration -I./subversion/include -I./subversion -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 -I/tc_work/fleck/subversion-1.7.6/sqlite-amalgamation -o tools/server-side/mod_dontdothat/mod_dontdothat.lo -c tools/server-side/mod_dontdothat/mod_dontdothat.c tools/server-side/mod_dontdothat/mod_dontdothat.c:25:19: error: httpd.h: No such file or directory tools/server-side/mod_dontdothat/mod_dontdothat.c:26:25: error: http_config.h: No such file or directory (plus many more) ...so obviously I need some Apache headers. What tarball(s) do I need to obtain and install to provide the needed headers? 1.7.6 attempts to build mod_dontdothat even when Apache is not installed. I've just written a release note describing one workaround for building without Apache. Does this work for you: http://subversion.apache.org/docs/release-notes/1.7#mod_dontdothat-issue -- Philip
Re: Compilation errors building subversion 1.7.6: missing headers
David Fleck dcfl...@gmail.com writes: Building from tarballs on SUSE 11.1. I thought I had all the necessary dependencies, but I get this error message: /bin/sh /tc_work/fleck/subversion-1.7.6/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -Werror=implicit-function-declaration -I./subversion/include -I./subversion -I/usr/local/apr/include/apr-1 -I/usr/local/apr/include/apr-1 -I/tc_work/fleck/subversion-1.7.6/sqlite-amalgamation -o tools/server-side/mod_dontdothat/mod_dontdothat.lo -c tools/server-side/mod_dontdothat/mod_dontdothat.c tools/server-side/mod_dontdothat/mod_dontdothat.c:25:19: error: httpd.h: No such file or directory tools/server-side/mod_dontdothat/mod_dontdothat.c:26:25: error: http_config.h: No such file or directory (plus many more) ...so obviously I need some Apache headers. What tarball(s) do I need to obtain and install to provide the needed headers? On Wed, Aug 29, 2012 at 11:42 AM, Philip Martin philip.mar...@wandisco.com wrote: 1.7.6 attempts to build mod_dontdothat even when Apache is not installed. I've just written a release note describing one workaround for building without Apache. Does this work for you: http://subversion.apache.org/docs/release-notes/1.7#mod_dontdothat-issue -- Philip Yes, that appears to resolve the issue. Thanks!
Re: vendor branch merge: how to highlight patches for review?
Ideally, after the merge (but before commit) I'd like to be able to run a command like: svn diff --show-patches-to-vendor-code Output: list of lib files that I've changed at any point since the previous vendor drop. Could I do something like diff the (pre commit) project working copy against ^/vendor/libcomplex/2.0? [SNIP] I think that last command needs the 2nd form of 'svn diff' syntax, because you're comparing an (arbitrary) url with a working copy path: So that would be: $ svn diff --summarize \ --old=http://svn.example.com/repos/vendor/libcomplex/2.0 \ --new=path/to/workingcopyofcalc/libcomplex Interesting. Thank you. Couple of questions: 1. --summarize complains that it can only work on URL-URL diffs. Is there a work around? 2. Running without --summarize works, but I see a ton of mergeinfo entries like: Property changes on: Somefile ___ Modified: svn:mergeinfo Merged /branches/path/Somefile:r19415-19622 This is accurate I suppose (what's it indicate?), but gets in the way of seeing the list of patched files. i.e. Somefile is unrelated to any of my changes. Can this be suppresed? 3. Running the above diff also outputs lines related to some files that I know I never modifed, but did recive updates via the merge. Oddly, these are all binary files. Index: Path/to/bin.dat === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream What does this indicate? Thank you
Re: Pristiine copy not present
Simon Heffer wrote on Wed, Aug 29, 2012 at 10:17:42 +: Hi, So some small progress made by using yet another fresh checkout. Now I'm getting: svn: E20: Commit succeeded, but other errors follow: svn: E720005: Error bumping revisions post-commit (details follow): svn: E720005: Can't set file 'filename' read-write: Access denied Is this access in to the wc.db file or the pristine folders it cannot access? I think that's the permissions of the actual on-disk file (and the directory that contains it). It's a bit hard to tell without knowing whether the error message mentioned a versioned file or a file under the .svn dir. svn info filename gives: svn: E155037: Previous operation has not finished; run 'cleanup' if it was inter rupted Simon This message has been scanned by MailController - portal1.mailcontroller.co.uk
Question about web access to SVN repository ....
My current configuration is Subversion 1.7.6 with Apache server 2.2.22 and TortoiseSVN client (not sure which version at the moment), running on Windows 2003 Server. On the local machine, I can access the SVN repository through the file:/// file:///\\%3cpath_to_repository path_to_repository directive as well as the http://localhost/ http://localhost/%3cpath_to_repository path_to_repository URL. I can also access the URL from a remote host with http://IP_Address/ http://IP_Address/%3cpath_to_repository path_to_repository. When I do this, however, the presentation of the subversion repository appears in a directory format similar to what you would normally see by accessing a pub site with ftp. Question: How can I get the presentation of the SVN repository from the remote host to appear in the same format as shown on the local machine? Am I missing a shared object (.so) load module? Do I need an additional entry in httpd.conf? It seems the solution here is for the web server to exec the TortoiseSVN client software as part of retrieving the SVN repository contents. Any help appreciated. David Anastasio Jacobs Technology / ETASS AFNet OPS Support (ESC/HNID) 3 Eglin Street; Building 1612 Hanscom AFB DSN: 845-4682 COMM: (781) 225-4682 smime.p7s Description: S/MIME cryptographic signature
Handling non-sequential vendor releases
Hi all, I've been thinking up a repository structure for some personal projects that I am planning. These projects are extensions for a third-party application, so, naturally, I want to keep versions of this third-party application in a vendor branch so that they're available to test against. - vendors/ - VendorA/ - 1.0.0/ - 1.1.0/ - current/(identical to 1.1.0) The issue that occurred to me is that this vendor is known to release versions out of order due to important bugfixes. Meaning, it's possible for them to release v1.0.1 /after/ they've released v1.1.0. I think this a fairly common situation, but the usual method of importing to current (with svn_load_dirs or an equivalent) and then tagging seems to break down here, at least in my mind. My first thought was to keep separate current directories for each minor release, like so: - vendors/ - VendorA/ - 1.0.0/ - 1.1.0/ - current-1.0/(identical to 1.0.0) - current-1.1/(identical to 1.1.0) But that seems a bit much. Another thought was to simply branch the most recent release in that minor release, like so: - vendors/ - VendorA/ - 1.0.0/ - 1.0.1/ (branched from and currently identical to 1.0.0) - 1.1.0/ - current/ (identical to 1.1.0) Now, instead of importing the vendor's 1.0.1 package into current, I would import it into 1.0.1. This seems like a much cleaner solution to me, but I'm always afraid that there's something I'm missing. Can anyone see anything wrong with this solution? Is there a better way? Thanks in advance, Ryan
Re: Question about web access to SVN repository ....
Guten Tag Anastasio, David M CTR USAF AFMC AFLCMC/HNID, am Mittwoch, 29. August 2012 um 21:40 schrieben Sie: It seems the solution here is for the web server to exec the TortoiseSVN client software as part of retrieving the SVN repository contents. This is not (easily) possible, as Tortoise's project browser is a stand alone application with no interfaces which can be used by your httpd in any way I know of. You would have to create your own web application to do that. What you really want is one of the web frontends for SVN, like WebSVN or others. http://www.websvn.info/ 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.030-2 1001-310 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
Adding older vendor releases to an established vendor branch
Hello again, As I mentioned in my previous message, I've been thinking about a repository structure for some personal projects I'll be working on. Another issue that occurred to me---also related to vendors releases, but different from the issue in my other message---is what to do when you decide that you want to test against a version of VendorA's code that is older than the oldest version in your vendor branch. For example, your vendor branch currently looks like this: - vendors/ - VendorA/ - 2.0.0/ - 2.1.0/ - current/ This is probably a sign of poor planning, but what if you decide that you also want to test against v1.0.x of VendorA's code? Does anyone have any thoughts on how to handle, or experience with handling, such a situation? Thanks again, Ryan
Re: vendor branch merge: how to highlight patches for review?
On Wed, Aug 29, 2012 at 02:08:31PM -0400, Q. Chap wrote: Interesting. Thank you. Couple of questions: 1. --summarize complains that it can only work on URL-URL diffs. Is there a work around? No. Well, maybe you could do something like svn diff | grep ^Index to obtain a list of filenames from the full diff output? 2. Running without --summarize works, but I see a ton of mergeinfo entries like: Property changes on: Somefile ___ Modified: svn:mergeinfo Merged /branches/path/Somefile:r19415-19622 This is accurate I suppose (what's it indicate?), but gets in the way of seeing the list of patched files. i.e. Somefile is unrelated to any of my changes. Can this be suppresed? Not in Subversion 1.7, unfortunately. You will be able to suppress this in Subversion 1.8, which will ship with new --ignore-properties and --properties-only options to make everyone happy. For the time being, there is another third-party utility called filterdiff which might be able to get rid of the property diffs. It is part of the patchutils package, see http://cyberelk.net/tim/software/patchutils/ You could also write your own post-processing filter. 3. Running the above diff also outputs lines related to some files that I know I never modifed, but did recive updates via the merge. Oddly, these are all binary files. Index: Path/to/bin.dat === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream What does this indicate? Not sure. Did these files also receive mergeinfo changes perhaps?
Re: Handling non-sequential vendor releases
On Wed, Aug 29, 2012 at 04:02:40PM -0400, Ryan Lange wrote: Now, instead of importing the vendor's 1.0.1 package into current, I would import it into 1.0.1. This seems like a much cleaner solution to me, but I'm always afraid that there's something I'm missing. Can anyone see anything wrong with this solution? Is there a better way? You can use 'svn import' to import vendor releases, rather than using svn_load_dirs.pl. Put the releases into /vendor/1.0.1, /vendor/1.2.0, etc. As of Subversion 1.6 this won't store any redundant content in the repository because of the representation-sharing feature (http://subversion.apache.org/docs/release-notes/1.6.html#rep-sharing). And then merge differences between arbitrary vendor releases into your own code like this: svn checkout http://svn.example.com/trunk cd trunk svn merge ^/vendor/1.0.1 ^/vendor/1.0.2 . See also this recent discussion about the same issue: http://mail-archives.apache.org/mod_mbox/subversion-users/201208.mbox/%3C2E34DA2E-B7B8-4356-AA4E-579861635498%40ryandesign.com%3E
Re: Adding older vendor releases to an established vendor branch
On Wed, Aug 29, 2012 at 04:16:59PM -0400, Ryan Lange wrote: Hello again, As I mentioned in my previous message, I've been thinking about a repository structure for some personal projects I'll be working on. Another issue that occurred to me---also related to vendors releases, but different from the issue in my other message---is what to do when you decide that you want to test against a version of VendorA's code that is older than the oldest version in your vendor branch. For example, your vendor branch currently looks like this: - vendors/ - VendorA/ - 2.0.0/ - 2.1.0/ - current/ This is probably a sign of poor planning, but what if you decide that you also want to test against v1.0.x of VendorA's code? Does anyone have any thoughts on how to handle, or experience with handling, such a situation? Thanks again, Ryan A vendor branch usually means that you pick a certain vendor code base version A as a baseline for your own product, and make modifications relative to version A. In this model you're usually only interested in future vendor releases, since they might have fixed bugs that still affect your own product. What you describe now sounds more like code developed by the vendor is used in your product, but doesn't form a baseline for your product. In which case it is more like an external dependency. You'd usually treat the vendor code as a library that you depend on, which might reside in some subdirectory of your own source tree (e.g. it could be an external, see http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html). Then you could swap the content of the directory which the vendor code resides in with the appropriate version you want to test against. Or you install the vendor code as a library on your system and compile different builds of your own product linked against different versions of the vendor library, and run tests on each build.
Re: vendor branch merge: how to highlight patches for review?
Couple of questions: 1. --summarize complains that it can only work on URL-URL diffs. Is there a work around? No. Well, maybe you could do something like svn diff | grep ^Index to obtain a list of filenames from the full diff output? Interesting idea. Out curiosity, what is the cause for the limitation? 2. Running without --summarize works, but I see a ton of mergeinfo entries like: Property changes on: Somefile ___ Modified: svn:mergeinfo Merged /branches/path/Somefile:r19415-19622 This is accurate I suppose (what's it indicate?), but gets in the way of seeing the list of patched files. i.e. Somefile is unrelated to any of my changes. Can this be suppresed? Not in Subversion 1.7, unfortunately. You will be able to suppress this in Subversion 1.8, which will ship with new --ignore-properties and --properties-only options to make everyone happy. The --ignore-properties option seems like a big hammer for this use case. I guess that I'm thinking svn:mergeinfo is more of an automatically maintained internal detail to aid in merge tracking. Seems a bit different than other properties like ignore or externals that are more closely related to the actual content of my code-base. Wrong? Too late to request an --ignore-housekeeping option to svn diff for 1.8? :-) 3. Running the above diff also outputs lines related to some files that I know I never modifed, but did recive updates via the merge. Oddly, these are all binary files. Index: Path/to/bin.dat === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream What does this indicate? Not sure. Did these files also receive mergeinfo changes perhaps? No, those files do not have any mergeinfo at all. At least for the couple I checked. They do have changes brought in by the merge, though. Does this make any sense?
Re: vendor branch merge: how to highlight patches for review?
On Aug 29, 2012, at 13:08, Q. Chap wrote: [SNIP] I think that last command needs the 2nd form of 'svn diff' syntax, because you're comparing an (arbitrary) url with a working copy path: So that would be: $ svn diff --summarize \ --old=http://svn.example.com/repos/vendor/libcomplex/2.0 \ --new=path/to/workingcopyofcalc/libcomplex Interesting. Thank you. Couple of questions: 1. --summarize complains that it can only work on URL-URL diffs. Is there a work around? 2. Running without --summarize works, but I see a ton of mergeinfo entries like: Property changes on: Somefile ___ Modified: svn:mergeinfo Merged /branches/path/Somefile:r19415-19622 This is accurate I suppose (what's it indicate?), but gets in the way of seeing the list of patched files. i.e. Somefile is unrelated to any of my changes. Can this be suppresed? 3. Running the above diff also outputs lines related to some files that I know I never modifed, but did recive updates via the merge. Oddly, these are all binary files. Index: Path/to/bin.dat === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream What does this indicate? Since you appear to be having difficulties getting the URL-to-directory form of svn diff working for your use case, why not use the URL-to-URL version I originally posted? On Aug 28, 2012, at 17:26, Ryan Schmidt wrote: you can see which files you changed using this command: $ svn diff --summarize \ http://svn.example.com/repos/vendor/libcomplex/1.0 \ http://svn.example.com/repos/calc/libcomplex It answers the question you asked, which was: On Aug 28, 2012, at 15:57, Q. Chap wrote: I'd like carefully examine the files that I've previously patched just to ensure things still make sense or are required. That is, the command I previously posted will indicate to you what files you previously patched. You can then merge the new version into your working copy, and carefully examine those files and test the project as much as you like before committing them.
Re: Question about web access to SVN repository ....
Anastasio, David M CTR USAF AFMC AFLCMC/HNID wrote: My current configuration is Subversion 1.7.6 with Apache server 2.2.22 and TortoiseSVN client (not sure which version at the moment), running on Windows 2003 Server. On the local machine, I can access the SVN repository through the file:/// file:///\\%3cpath_to_repository path_to_repository directive as well as the http://localhost/ http://localhost/%3cpath_to_repository path_to_repository URL. I can also access the URL from a remote host with http://IP_Address/ http://IP_Address/%3cpath_to_repository path_to_repository. When I do this, however, the presentation of the subversion repository appears in a directory format similar to what you would normally see by accessing a pub site with ftp. Question: How can I get the presentation of the SVN repository from the remote host to appear in the same format as shown on the local machine? I don't think I understand the question. Using the TSVN repo browser should give you the same representation of the repo regardless of the protokoll or if it's local or remote. Or do you want to access the repo remotely via web browser? -- Lorenz
