On 4/29/07, Ryan Schmidt <subversion-2007b@ryandesign.com> wrote:
>
> > 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.
>
Thanks for replying Ryan
1 (as you said) copy the old version tag to the new version number, then
check out
the new version tag
2 update that working copy (using whatever tool that makes sure the WC is
exactly the same as a fresh install of the new version, excluding the .svn
files)
3 svn add/del (+rename/move if possible)
4 commit back to the new version number tag
5 delete working copy
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
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.
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.
OK if svn_load_dirs.pl needs current, then create it just for that purpose -
or perhaps if what I'm proposing is more logical, svn_load_dirs.pl should be
tweaked to allow the user to select the source/targets rather than
hard-coding them.
I've never run a per script and since I have other diff/merge tools I feel
more comfortable with them, but if I have time I'll have a look at it.
Does it actually do a file-content diff comparison to determine what's
changed?
Received on Sun Apr 29 08:40:11 2007