>
> 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.
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.1release 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.
Received on Sat Apr 28 22:30:19 2007