On Apr 29, 2007, at 01:39, hans henderson wrote:
>> On 4/29/07, Ryan Schmidt 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.
>
> 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.
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.
> 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).
> 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 recommend you accept the existence of "current" in your vendor
branch structure. You don't need to do anything with it or use it for
any other purpose, other than to import new versions with
svn_load_dirs.pl. Then again, loading new versions is the only thing
you'll be doing with the /vendor section anyway.
Note that the name "current" is not hard-coded at all, but specified
by you on the command line when you run svn_load_dirs.pl.
> 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.
Sure, feel free to use whatever tool you prefer. I just think
svn_load_dirs.pl is great because it can do some fairly involved
rearranging, and all you have to do is run one command. Doing it by
hand would surely take much longer.
> Does it actually do a file-content diff comparison to determine
> what's changed?
I haven't read the complete source code, but my understanding is that
it works this way:
- It checks out a working copy of current (or whatever name you've
supplied on the command line for this directory).
- You also give it a local directory containing the new code to be
imported.
- For every file in the new code directory which has the same name as
in the working copy, it copies the file over.
- For the remaining items, it "looks" (by some mechanism that I'm not
clear on, though I think it's just by filename) to see if the file
might have been renamed. If it determines that this has happened, it
issues "svn move" commands.
- If there are any remaining items where it cannot tell whether a
move or rename might have taken place, it prompts the user.
- Once the user has identified any remaining files that were renamed,
it issues more "svn move" commands.
- For any remaining items, it issues "svn add" and "svn delete"
commands as needed.
- Finally it commits all the changes.
- It even then checks out the code from the repository again and
compares it with the original directory of new code to make sure it's
now identical.
- And it creates the release tag with the name you provided.
I don't think svn_load_dirs.pl does diffs of files at any point;
don't think there's any reason for it to either. Unless perhaps it
does so in order to determine whether files are sufficiently
"similar," to guess that a rename has taken place. But that would be
a bit advanced and I don't think it does that.
Update: I grepped svn_load_dirs.pl for "diff" and can now say that
the only time it does a diff is when it is comparing the re-checked-
out working copy to the original to-be-imported directory at the very
end.
But you really don't need to concern yourself with all that. Just
accept the high-level overview: svn_load_dirs.pl is a black box that
accomplishes the following:
Let's say you have v1.2.0 of something in /vendor, and now v1.2.1 has
been released and you want to load it in. Before you run
svn_load_dirs.pl it looks like this:
/vendor/
something/
current/
1.2.0/
The "current" directory contains v1.2.0, and so does the tag
directory "1.2.0".
Now you run svn_load_dirs.pl. When it's done, just like magic, it
looks like this:
/vendor/
something/
current/
1.2.0/
1.2.1/
Now "current" and "1.2.1" both contain v1.2.1. Simple. It loads the
provided directory into Subversion, on top of an earlier version of
the same software that's already in the repository. Does exactly what
it says on the tin.
--
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 Sun Apr 29 10:35:07 2007