On Apr 28, 2007, at 15:29, hans henderson wrote:
> Make sure you read the section in the manual regarding "Vendor
> Branches"
> http://svnbook.red-bean.com/en/1.1/ch07s05.html
>
> OK, I've read this and found it very helpful, and in fact now
> understand how merge works much better than I did before with a
> concrete example that relates to my needs.
>
> In fact I read it thoroughly enough and believe I've understood it
> well enough to question a couple of minor bits. If these do in fact
> turn out to be errata, please advise of where I should post it
> where the authors will see it.
>
> Example scenario:
>
> repos/website/trunk
> repos/website/tags
> repos/website/branches
> repos/website/vendors/apache-friends/xamppcore
> repos/website/vendors/apache-friends/perl-add-on
> repos/website/vendors/apache-friends/ruby-add-on
> repos/website/vendors/wordpress/core
> repos/website/vendors/wordpress/themes/k2
> repos/website/vendors/wordpress/plugins/
> repos/website/vendors/wordpress/drupal/core
> repos/website/vendors/wordpress/drupal/plugins
> ...
> etc
> Using as an example
> repos/website/vendors/apache-friends/xamppcore
> the book recommends creating a /current (sort of like trunk for
> that vendor branch) as well as a version snapshot directory (just
> like a tag). However, since no changes will take place in current,
> and no one but me (the svn admin) will need to point to it (the
> other users will just get the code from the trunk location) I
> question the need for current at all, why not just use the per-
> version tag locations as the source for copies/checkouts/merge-
> compares?
> repos/website/vendors/apache-friends/xamppcore/v1.60a
> repos/website/vendors/apache-friends/xamppcore/v1.61
>
> I agree that it's a minor quibble, as the extra directory takes up
> little time or space to create, but I don't see any need for it at
> all and it's one more possible complication.
The "current" directory is needed by the svn_load_dirs.pl script.
Well, if you were importing a new version manually, you'd need
"current" too. Where else would you load your new files?
svn_load_dirs.pl does it this way:
1. Check out a working copy of "current".
2. Put the new files in there, run "svn add" and "svn delete" as
necessary.
3. Commit.
4. Copy "current" to the new version tag.
How would you do it if you didn't have "current"? You could first
copy the old version tag to the new version number, then check out
the new version tag and update it. But then there would be a revision
of the repository in which the new version tag was actually the old
version of the software, and that's misleading.
> Another anomaly I found I think is perhaps more of an actual error?
>
> From "the book" (nightly PDF p124)
>
>> To perform this upgrade, we checkout a copy of our vendor branch,
>> and replace the code in
>> the current directory with the new libcomplex 1.1 source code. We
>> quite literally copy new
>> files on top of existing files, perhaps exploding the libcomplex
>> 1.1 release tarball atop our existing
>> files and directories. The goal here is to make our current
>> directory contain only the libcomplex
>> 1.1 code, and to ensure that all that code is under version
>> control. Oh, and we want to
>> do this with as little version control history disturbance as
>> possible.
>>
>> After replacing the 1.0 code with 1.1 code, svn status will show
>> files with local modifications
>> as well as, perhaps, some unversioned or missing files. If we did
>> what we were supposed to
>> do, the unversioned files are only those new files introduced in
>> the 1.1 release of libcomplex—
>> we run svn add on those to get them under version control. The
>> missing files are files
>> that were in 1.0 but not in 1.1, and on those paths we run svn
>> delete. Finally, once our current
>> working copy contains only the libcomplex 1.1 code, we commit the
>> changes we made to
>> get it looking that way.
>
> If I just copy over the "current" (now old) version with the new
> one, how is that going to result in any files getting deleted -
> there won't be any "missing" ones for me to "svn delete".
>
> This isn't a direct problem for me, as I have a third-party diff/
> merge tool I can use to sync between an unversioned "new" install
> and the checked-out "current/old" working copy to get the WC to the
> necessary new state, or I could delete all out all but the
> hidden .svn files and *then* install the new version, or perhaps
> I'd even go so far as to figure out svn_load_dirs.pl, but I think
> this bit of the docs needs tweaking, or someone following it will
> end up with orphaned files from old versions, possible a lot of
> them over multiple upgrades in time, causing clutter and confusion
> in the future.
Hmm. I agree with you. If you just untar a new version over a working
copy of an old version, tar won't delete any files. The wording
should be changed to reflect this. Feedback on the book can be sent
to the book's mailing list. See the bottom of http://svnbook.org/
It's not hard to figure out svn_load_dirs.pl. I believe it's
explained in the book, and I've also written numerous messages to the
mailing list showing examples of how to use it. Here's a recent one
where I was quite explicit:
http://svn.haxx.se/users/archive-2007-04/0719.shtml
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 28 22:44:02 2007