On 4/29/07, Ryan Schmidt <subversion-2007b@ryandesign.com> wrote:
>
> On Apr 29, 2007, at 01:39, hans henderson wrote:
> > I'm not sure what's misleading, the new version tag will only have
> > the previous version files in it for the short time it takes to do
> > steps 2-4, after that it will be accurate.
>
> Exactly, it will be inaccurate for that one revision. If you don't
> care about that, then maybe you don't need "current." I was just
> trying to give my best guess for why "current" existed, since that
> was your question. You're of course free to implement your own
> process which doesn't use a "current."
>
> But your new method above does remind me of another discussion taking
> place on this list right now, "Why have a trunk dir, anyway?!":
>
> http://svn.haxx.se/users/archive-2007-04/0898.shtml
>
> Some of the statements made there may apply to you as well. In that
> thread, one response was that, in the usual development model, it is
> generally beneficial to have a single place (trunk) where all
> development takes place and from which branches and tags can be made.
> The log of the trunk shows only development taking place and isn't
> cluttered with a bunch of copy commands. And if you want to develop
> new code, well, you know exactly where you need to go: the trunk.
> Similarly, in the vendor branch model, I think it's beneficial to
> have a single place (current) where all importing takes place and
> from which tags can be made.
OK, given the fact that I may use svn_load_dirs.pl and your comments, I'll
go along, it usually makes sense to follow the way it's usually done.
And since then I have thought of another reason why I need current with this
specific project, but maybe that use conflicts with the above usual
practice? My original tree example:
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
I've got all these different components of my overall website, and should
keep the individual tags separate for version control purposes. However it
would be useful to have a "all base code integrated together but without any
of "our stuff"" branch, and I'm thinking I can use current for that.
At any given time, a comparison of
repos/website/trunk
and
repos/website/vendors/current
will show ALL the "our stuff" modifications
and exporting current will give a virginal but functioning base platform
without any of those modifications.
But I'm not sure if that would make it more difficult to to use it with
svn_load_dirs.pl ?
> As the SVN admin, I don't need current, nor do the other
> > committers, as they will be getting their vendor code from trunk.
> > No "our stuff" changes will take place anywhere in the vendor tree.
>
> Wait, what do you mean, "the other committers [...] will be getting
> their vendor code from trunk"? What trunk? A vendor branch as
> described in the book does not have a trunk; it has current, which is
> the vendor branch analog for trunk. I imagine they didn't call it
> "trunk" because they wanted to emphasize the difference between a
> place where you are doing active development (trunk) and a place
> where you are merely loading the work of others and must absolutely
> not do any development of your own (current).
No I mean the usual trunk. From the book:
>by storing the currently supported vendor drop in your own version control
system, the members of your project never need to question whether they have
the right version of the vendor's data. They simply receive that correct
version as part of their regular working copy updates
and
>You then copy that [vendor branch] subdirectory into your main development
branch (for example, /trunk) at the appropriate location. You always make
your local changes in the main development branch. With each new release of
the code you are tracking you bring it into the vendor branch and merge the
changes into /trunk, resolving whatever conflicts occur between your local
changes and the upstream changes.
I mentioned in my "step 6" that I might be merging into a temporary branch
instead:
>6 merge comparing previous version to new version, either into trunk or a
branch if the new version has a lot of changes, i.e. resolving conflicts
will take a long time.
Thanks a lot for taking so much time to explain the internal workings of the
svn_load_dirs.pl script as well, I'll try to make time to check it out once
I have perl up and running.
BTW WinMerge is pretty efficient, and has a graphic diff built-in. I set it
up to work basically just like an svn merge:
1 compare a virgin v1.60a install and a virgin v1.61 install
2 show only "unique to old" and svn delete them from my WC - some were
rename/moves, so do svn move on those
3 show only "unique to new" and tell it to copy them all into the WC tree,
then do a global svn add
4 show only "changed" and copy them over (nothing else needed)
finally, so a direct compare of the virgin new install and the WC, filtering
out the .svn stuff, to confirm they are identical, commit and tag.
Not as automated, but works for me. . .
Thanks again for your help.
Received on Sun Apr 29 14:41:31 2007