Eric Gillespie wrote:
>
> Blair Zajac <bzajac@demografx.com> writes:
>
> > If you have little projects and only a few renames and deletes and
> > feel like taking the time to make sure that the new vendor branch
> > exactly matches the old one, then sure, typing in those commands is
>
> Some of the projects are small, some are large; renames and deleted
> and added files are rarely painful, but i would not trust it to
> automation.
What is the concern about trust?
One of my concerns was that the script wouldn't do the job correctly and
the checked in vendor branch wouldn't match exactly the directory being
imported.
To handle this and to ensure that the script did its job correctly, it
does the following:
1) Run all the svn add and svn rm's it needs to and copy all the
files from the imported directory to the working copy.
2) svn commit
3) Make a cheap copy tag via "svn cp URL URL" on the repos itself.
4) "svn update" its working copy to include the tag.
5) "diff -r -x .svn" on the imported directory and the working copy
tag to verify that everything is exactly correct.
One outstanding issue is that the script runs automatically and
doesn't ask for user confirmation on anything except for renames,
so if it does something unwanted, then it can leave the repository
in an undesirable state.
Currently the work around for this is that the user make a backup
of the repository itself before running the script. This is a
problem, because it may require an admin to make the snapshot.
One long-term solution is to show all the steps that the script
does (which it does already) and ask for confirmation before doing
any commits on the repository (which is easy).
> What i don't want to see is this script become blessed as the way
> to manage vendor branches, when it does more than CVS did, and
> arguably too much. I suspect it will become a source of complaints,
> as it will not be flexible enough to do what people want.
What does it do more than CVS did? Since svn does more than CVS
does, why shouldn't the vendor support be more powerful? How is it
not flexible enough? What's missing to make it more flexible?
There are no specific issues with the script here, just generalities
that it automates too much, may "become a source of complaints" and
isn't "flexible enough."
Here's my request. Run the script to import a bunch of stuff and see
what doesn't work about it and let us know those things. Those things
that don't work can be fixed.
>
> > In the mean time, keep your code quality comments to yourself.
>
> I think Karl already said anything i would say in my defense here,
> but i'd better say it too. Don't take offense; i didn't mean
> anything about the code quality of your script, per se. It's just
> that so often when a tool has a problem, the answer is "Oh, that's
> easy, just write a perl script." As i said above, i just think
> this script is being over-sold.
So what a solution here then? Is it porting the functionality in the
script to be in svn itself?
Best,
Blair
--
Blair Zajac <blair@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 25 20:21:53 2002