Re: Managing Vendor Branches
On Fri, Feb 26, 2010 at 09:49:56PM -0800, Jeff Mott wrote: > I've recently needed to track changes for vendor code drops, so I read > the SVN book's vendor branches chapter. But I'm not entirely happy > with part of the procedure, so I'd like to talk it out and, I hope, > find a better way. > > The part I hope to improve is when I have a versioned code drop in the > /vendor directory, then the vendor provides a new code drop. The SVN > book suggests that I should copy the new files over top of the files > in my working copy. Then I need to SVN add and delete as needed. I saw > there's a script to ease this process, but I still feel that this > should be easier. > > It seems to me that comparing two trees, even unrelated trees, is > something SVN is very good at. In some way, yes. In some ways, no :) What it cannot do (and that is a major problem) is that it cannot reliably compare a working copy to a URL in the repository. It can however reliably compare URLs to URLs. > So if I have /vendor/code-drop-v1 and > /vendor/code-drop-v2, then it seems SVN should be able to derive the > changes between the two and apply those changes to my working copy. > > Can I do this? Yes, you can do a 2-URL merge: cd working-copy svn update # straighten potentially mixed-revision working copy svn merge ^/vendor/code-drop-v1 ^/vendor-code-drop-v2 . This says "merge the difference between code-drop-v1 and code-drop-v2 into my working copy". The dot at the end is implied if you don't specify it. However, beware of renames the vendor made which affects files that you were modifying. Double-check that these files contain the correct content at their new location. Also note that importing a new vendor drop to a different URL than the old one will waste some disk space, unless you enable "rep-sharing" (see the file db/fsfs.conf in the repository). Stefan
Re: Managing Vendor Branches
On Feb 26, 2010, at 23:49, Jeff Mott wrote: > I've recently needed to track changes for vendor code drops, so I read > the SVN book's vendor branches chapter. But I'm not entirely happy > with part of the procedure, so I'd like to talk it out and, I hope, > find a better way. > > The part I hope to improve is when I have a versioned code drop in the > /vendor directory, then the vendor provides a new code drop. The SVN > book suggests that I should copy the new files over top of the files > in my working copy. Then I need to SVN add and delete as needed. I saw > there's a script to ease this process, but I still feel that this > should be easier. > > It seems to me that comparing two trees, even unrelated trees, is > something SVN is very good at. So if I have /vendor/code-drop-v1 and > /vendor/code-drop-v2, then it seems SVN should be able to derive the > changes between the two and apply those changes to my working copy. > > Can I do this? I think you may be confusing two different things. First, there the matter of getting the remote code into your local Subversion repository as-is. Second, there's the matter of making a branch of that vendor code that you will modify locally. These are both necessary and two separate things. For getting the remote vendor code into your own repository, the book addresses taking a tarball and using "svn import" to get it into your repository, and then using copy-on-top in a working copy to keep it updated later. The svn_load_dirs.pl script you mention is an easier way to keep the vendor software updated in your repository. I have just been informed that an even easier way is to simply "svn merge" the relevant changes from the remote repository into your own, assuming the vendor manages their software in Subversion too. For more information on this latest development please see: http://svn.haxx.se/users/archive-2010-02/0226.shtml The second issue is making a copy of that vendor code and making local changes to it. The key point to realize is that the vendor's code in /vendor in your repository shall be pristine -- you are not to make any changes here, except to update it to a later version of the vendor's software. If you want to make your own changes to their software, you must first copy a specific version of it to some place in your repository outside of /vendor. Let's say you are tracking the code for MySQL and need to maintain local changes to it. You'd have /vendor/mysql/current which represents an unaltered copy of MySQL's source code from, let's say, version 5.1.44, which you've brought in using "svn import". You'll probably also copy /vendor/mysql/current to /vendor/mysql/5.1.44 as a sort of tag. To make changes, you'll copy /vendor/mysql/5.1.44 to let's say /mysql in the same repo. Then you can modify /mysql to your heart's content. Later, when MySQL AB releases version 5.1.45, you'll want to do two things: First, you'll want to update the pristine copy in /vendor/mysql/current. To do this, you can do it the book way: check out a working copy of /vendor/mysql/current, untar the 5.1.45 tarball on top of it, deal with svn add's and svn delete's, and commit. Or, you can use svn_load_dirs.pl to do this for you. Or you can "svn merge" the changes from MySQL AB's repository's 5.1.44 tag to their 5.1.45 tag into a working copy of /vendor/mysql/current (assuming they use a Subversion repository; I can't find out if they do). Whatever method you use, you'll also make a new tag by copying /vendor/mysql/current to /vendor/mysql/5.1.45. Now that you've updated your untouched copy of their code in /vendor/mysql, you can "svn merge" the changes from /vendor/mysql/5.1.44 to /vendor/mysql/5.1.45 into a working copy of your /mysql area to update your version. Given the new developments C. Michael Pilato mentioned, perhaps we can dispense with the whole first part of this (i.e. dispense with having a /vendor directory at all) and exclusively merge from the remote upstream repository. If they also use Subversion. I haven't had occasion to try this new method yet. But it would certainly simplify things.
Re: "svnlook pl --revprop" does not work on transactions?
On Fri, 2010-02-26 at 22:15 -0800, Alexey Neyman wrote: > Hi all, > > It seems that I encountered a bug in 'svnlook pl --revprop': it fails with > the following message: > > $ svnlook pl --revprop -t 10547-86b /svn/test-svn > svnlook: Invalid revision number '-1' > Looks like you need to use "svnlook info -t" to access the values of the properties that are going to be set on the revision-to-be (svn:log, svn:author, ...) -Olivier
Re: "svnlook pl --revprop" does not work on transactions?
On Feb 27, 2010, at 08:36, Olivier Dehon wrote: > On Fri, 2010-02-26 at 22:15 -0800, Alexey Neyman wrote: >> It seems that I encountered a bug in 'svnlook pl --revprop': it fails with >> the following message: >> >> $ svnlook pl --revprop -t 10547-86b /svn/test-svn >> svnlook: Invalid revision number '-1' > > Looks like you need to use "svnlook info -t" to access the values of the > properties that are going to be set on the revision-to-be (svn:log, > svn:author, ...) Why can't he use "svnlook pl --revprop -t" as he suggested? "svnlook help pl" suggests this should work. $ svnlook help pl proplist (plist, pl): usage: 1. svnlook proplist REPOS_PATH PATH_IN_REPOS 2. svnlook proplist --revprop REPOS_PATH List the properties of a path in the repository, or with the --revprop option, revision properties. With -v, show the property values too. Valid options: -r [--revision] ARG : specify revision number ARG -t [--transaction] ARG : specify transaction name ARG -v [--verbose] : be verbose --revprop: operate on a revision property (use with -r or -t) --xml: output in XML
Re: "svnlook pl --revprop" does not work on transactions?
On Sat, 2010-02-27 at 08:43 -0600, Ryan Schmidt wrote: > On Feb 27, 2010, at 08:36, Olivier Dehon wrote: > > On Fri, 2010-02-26 at 22:15 -0800, Alexey Neyman wrote: > >> It seems that I encountered a bug in 'svnlook pl --revprop': it fails with > >> the following message: > >> > >> $ svnlook pl --revprop -t 10547-86b /svn/test-svn > >> svnlook: Invalid revision number '-1' > > > > Looks like you need to use "svnlook info -t" to access the values of the > > properties that are going to be set on the revision-to-be (svn:log, > > svn:author, ...) > > Why can't he use "svnlook pl --revprop -t" as he suggested? "svnlook help pl" > suggests this should work. > Agreed, it might be a missing feature. I was just trying to suggest a workaround for what the OP wanted to achieve. -Olivier
Re: Managing Vendor Branches
- Original Message > From: Jeff Mott > I've recently needed to track changes for vendor code drops, so I read > the SVN book's vendor branches chapter. But I'm not entirely happy > with part of the procedure, so I'd like to talk it out and, I hope, > find a better way. > The part I hope to improve is when I have a versioned code drop in the > /vendor directory, then the vendor provides a new code drop. The SVN > book suggests that I should copy the new files over top of the files > in my working copy. Then I need to SVN add and delete as needed. I saw > there's a script to ease this process, but I still feel that this > should be easier. > It seems to me that comparing two trees, even unrelated trees, is > something SVN is very good at. So if I have /vendor/code-drop-v1 and > /vendor/code-drop-v2, then it seems SVN should be able to derive the > changes between the two and apply those changes to my working copy. > Can I do this? Here's what I do: In my repository I have a ThirdParty namespace (e.g. /ThirdParty) under which each Third-Party import has their own namespace (e.g. /ThirdParty//), with each having its own 'trunk', 'branches', and 'tags'. When I import a new version, it goes into the 'branches'. This then gets merged to 'trunk', and released to 'tags'. My projects then pull against the 'tag' using svn:externals. In this way, I can track the changes that happen from the vendor and even accept or deny some changes if I need to. For example, Qt has a niced add-on for supporting services/daemons - the Qt Service Class (http://doc.trolltech.com/solutions/qtservice/qtservice.html). However, their releases of it are targeted either at Windows OR Unix/Linux/Mac, but I need to support both; so using this method I merge them both together and use the merged result in my source. Personally, I think this helps as it is basically treating the vendor as another project in the repository. Of course, each of my projects have their own trunk/branches/tags, so this might not work for you if you're not doing that too...but you could probably find similar way. HTH, Ben
Re: "svnlook pl --revprop" does not work on transactions?
On Sat, Feb 27, 2010 at 3:25 AM, Alexey Neyman wrote:
> Hi all,
>
> It seems that I encountered a bug in 'svnlook pl --revprop': it fails with
> the following message:
>
> $ svnlook pl --revprop -t 10547-86b /svn/test-svn
> svnlook: Invalid revision number '-1'
Reproducible with tr...@911289.
>
> Observed with Subversion 1.6.6. Looks like offending code is this block in
> do_plist():
>
> ==
> if (path != NULL)
> ...
> else
> {
> SVN_ERR(svn_fs_revision_proplist(&props, c->fs, c->rev_id, pool));
> revprop = TRUE;
> }
> ==
>
> Note that it always uses svn_fs_revision_proplist(), even when '-t TXN' is
> passed. In this case, c->rev_id == SVN_INVALID_REVNUM (-1), and
> svn_fs_revision_proplist() rightfully fails.
>
> Shouldn't it be using svn_fs_txn_proplist() instead, just as
> get_property() chooses between svn_fs_txn_prop() and
> svn_fs_revision_prop()?
Think so. Do you want to submit a patch to fix this issue?
Lieven
How to install Subversion the right right with fronted by Apache 2.2.x
How to install Subversion the right right with fronted by apache 2.2.x Thanks, Earnest Jackson
catastrophic recovery required
Hi, I'm currently using svn with Berkeley DB, and just today when I try to access the repository I get the error "Could not open the requested SVN filesystem". When I ran "svnadmin recover", I get the following: svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery svnadmin: bdb: DB_LOGC->get: LSN 564/955694: invalid log record header svnadmin: bdb: Skipping log file e:\svn\db\log.000368: historic log version 10 svnadmin: bdb: DB_LOGC->get: log record LSN 564/955710: checksum mismatch svnadmin: bdb: DB_LOGC->get: catastrophic recovery may be required svnadmin: bdb: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery svnadmin: bdb: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery I've downloaded the Berkley DB binaries, and tried to run db_recover, but get the following error: c:\Program Files\Sleepycat Software\Berkeley DB 4.4.20\bin>db_recover -vech e:\svn\db Finding last valid log LSN: file: 565 offset 131910 db_recover: DB_LOGC->get: LSN 564/955694: invalid log record header db_recover: Skipping log file e:\svn\db\log.000368: historic log version 10 db_recover: DB_LOGC->get: log record LSN 564/955710: checksum mismatch db_recover: DB_LOGC->get: catastrophic recovery may be required db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery db_recover: PANIC: fatal region error detected; run recovery db_recover: unable to join the environment db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery My issue sounds similar to the one described here: http://svn.haxx.se/users/archive-2004-08/1341.shtml So I've deleted the __db* and lot.* files from the db directory, and tried to run the above command again, but now db_recover and svnadmin recover gives the following: c:\Program Files\Sleepycat Software\Berkeley DB 4.4.20\bin>db_recover -vech e:\svn-repair\db Finding last valid log LSN: file: 1 offset 28 c:\Program Files\Sleepycat Software\Berkeley DB 4.4.20\bin>svnadmin recover e:\svn-repair ?w‥u±oAER×RwAecw. ?Dμy?Y; -×’_aer×rw?]3\±oaa...@‥cre?!... -×’_§1|‥. svnadmin: AER×‥t2I 'e:/svn-repair/db' ao Berkeley DB ?u?~, ·i?i|a opening 'node s' table RE: Invalid argument svnadmin: bdb: file nodes (meta pgno = 0) has LSN [564][856423]. svnadmin: bdb: end of log is [1][28] svnadmin: bdb: e:\svn-repair\db\nodes: unexpected file type or format Yes the jibblish characters really do show up. I would really appreciate it if anyone could help anyway they can, as the last backup was a long time ago. :( Thanks in advance Robo
Re: "svnlook pl --revprop" does not work on transactions?
Olivier, Actually, I tried to check the presence of some custom properties (say, foo:bar and foo:baz), so svnlook info does not print them. These properties are essentially boolean (they're either present or not). So, I tried to check them all in one run. Instead, I am doing several "svnlook pg --revprop -t TXN", which works. Regards, Alexey. On Saturday 27 February 2010 06:36:44 am Olivier Dehon wrote: > On Fri, 2010-02-26 at 22:15 -0800, Alexey Neyman wrote: > > Hi all, > > > > It seems that I encountered a bug in 'svnlook pl --revprop': it fails > > with the following message: > > > > $ svnlook pl --revprop -t 10547-86b /svn/test-svn > > svnlook: Invalid revision number '-1' > > Looks like you need to use "svnlook info -t" to access the values of the > properties that are going to be set on the revision-to-be (svn:log, > svn:author, ...) > > -Olivier >
Re: "svnlook pl --revprop" does not work on transactions?
On Saturday 27 February 2010 11:35:24 am Lieven Govaerts wrote:
> > Note that it always uses svn_fs_revision_proplist(), even when '-t TXN'
> > is passed. In this case, c->rev_id == SVN_INVALID_REVNUM (-1), and
> > svn_fs_revision_proplist() rightfully fails.
> >
> > Shouldn't it be using svn_fs_txn_proplist() instead, just as
> > get_property() chooses between svn_fs_txn_prop() and
> > svn_fs_revision_prop()?
>
> Think so. Do you want to submit a patch to fix this issue?
Sure, attached.
Alexey.
Index: subversion/svnlook/main.c
===
--- subversion/svnlook/main.c (revision 917057)
+++ subversion/svnlook/main.c (working copy)
@@ -1687,7 +1687,14 @@
}
else
{
- SVN_ERR(svn_fs_revision_proplist(&props, c->fs, c->rev_id, pool));
+ if (! c->is_revision)
+ {
+ SVN_ERR(svn_fs_txn_proplist(&props, c->txn, pool));
+ }
+ else
+ {
+ SVN_ERR(svn_fs_revision_proplist(&props, c->fs, c->rev_id, pool));
+ }
revprop = TRUE;
}
Re: How to install Subversion the right right with fronted by Apache 2.2.x
On Feb 27, 2010, at 13:34, Earnest Jackson wrote: > How to install Subversion the right right with fronted by apache 2.2.x What have you tried so far? What documentation have you consulted? What operating system is this on?
Re: Managing Vendor Branches
On Sat, Feb 27, 2010 at 4:00 AM, Stefan Sperling wrote: > On Fri, Feb 26, 2010 at 09:49:56PM -0800, Jeff Mott wrote: >> I've recently needed to track changes for vendor code drops, so I read >> the SVN book's vendor branches chapter. But I'm not entirely happy >> with part of the procedure, so I'd like to talk it out and, I hope, >> find a better way. >> >> The part I hope to improve is when I have a versioned code drop in the >> /vendor directory, then the vendor provides a new code drop. The SVN >> book suggests that I should copy the new files over top of the files >> in my working copy. Then I need to SVN add and delete as needed. I saw >> there's a script to ease this process, but I still feel that this >> should be easier. >> >> It seems to me that comparing two trees, even unrelated trees, is >> something SVN is very good at. > > In some way, yes. In some ways, no :) > > What it cannot do (and that is a major problem) is that it cannot > reliably compare a working copy to a URL in the repository. > It can however reliably compare URLs to URLs. > >> So if I have /vendor/code-drop-v1 and >> /vendor/code-drop-v2, then it seems SVN should be able to derive the >> changes between the two and apply those changes to my working copy. >> >> Can I do this? > > Yes, you can do a 2-URL merge: > > cd working-copy > svn update # straighten potentially mixed-revision working copy > svn merge ^/vendor/code-drop-v1 ^/vendor-code-drop-v2 . > > This says "merge the difference between code-drop-v1 and code-drop-v2 > into my working copy". > The dot at the end is implied if you don't specify it. This is exactly what I thought I could do. But what happens is that SVN doesn't "update" the working copy files. Instead, it "replace"s them. And when it tries to replace a file with customizations, that creates a tree conflict. Is it supposed to work differently? Perhaps I'm doing something wrong... I'd really like to figure this out because this can make my life much easier. > However, beware of renames the vendor made which affects files that > you were modifying. Double-check that these files contain the correct > content at their new location. > > Also note that importing a new vendor drop to a different URL than > the old one will waste some disk space, unless you enable "rep-sharing" > (see the file db/fsfs.conf in the repository). > > Stefan >
Re: Managing Vendor Branches
On Sat, Feb 27, 2010 at 6:32 PM, Jeff Mott wrote: > On Sat, Feb 27, 2010 at 4:00 AM, Stefan Sperling wrote: >> On Fri, Feb 26, 2010 at 09:49:56PM -0800, Jeff Mott wrote: >>> I've recently needed to track changes for vendor code drops, so I read >>> the SVN book's vendor branches chapter. But I'm not entirely happy >>> with part of the procedure, so I'd like to talk it out and, I hope, >>> find a better way. >>> >>> The part I hope to improve is when I have a versioned code drop in the >>> /vendor directory, then the vendor provides a new code drop. The SVN >>> book suggests that I should copy the new files over top of the files >>> in my working copy. Then I need to SVN add and delete as needed. I saw >>> there's a script to ease this process, but I still feel that this >>> should be easier. >>> >>> It seems to me that comparing two trees, even unrelated trees, is >>> something SVN is very good at. >> >> In some way, yes. In some ways, no :) >> >> What it cannot do (and that is a major problem) is that it cannot >> reliably compare a working copy to a URL in the repository. >> It can however reliably compare URLs to URLs. >> >>> So if I have /vendor/code-drop-v1 and >>> /vendor/code-drop-v2, then it seems SVN should be able to derive the >>> changes between the two and apply those changes to my working copy. >>> >>> Can I do this? >> >> Yes, you can do a 2-URL merge: >> >> cd working-copy >> svn update # straighten potentially mixed-revision working copy >> svn merge ^/vendor/code-drop-v1 ^/vendor-code-drop-v2 . >> >> This says "merge the difference between code-drop-v1 and code-drop-v2 >> into my working copy". >> The dot at the end is implied if you don't specify it. > > > This is exactly what I thought I could do. But what happens is that > SVN doesn't "update" the working copy files. Instead, it "replace"s > them. And when it tries to replace a file with customizations, that > creates a tree conflict. > > Is it supposed to work differently? Perhaps I'm doing something > wrong... I'd really like to figure this out because this can make my > life much easier. > > >> However, beware of renames the vendor made which affects files that >> you were modifying. Double-check that these files contain the correct >> content at their new location. >> >> Also note that importing a new vendor drop to a different URL than >> the old one will waste some disk space, unless you enable "rep-sharing" >> (see the file db/fsfs.conf in the repository). >> >> Stefan >> > I just discovered that using --ignore-ancestry fixed the problem. This caused SVN to update rather than replace my working copy.
