This issue is not going to be settled by list discussion; it's going
to be settled by users doing imports and re-imports and seeing how
things work for them. As Blair says, if the script helps with that
process, then the script can be incrementally improved over time just
like any other part of Subversion. If it doesn't, people won't use
it.
So while I can't really call this thread off-topic, it's not
particularly helpful to anyone either. I humbly suggest it end, at
least until someone has a *concrete* suggestion for either making the
script better, or for otherwise addressing issue #599.
-K
Blair Zajac <blair@orcaware.com> writes:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 25 21:14:05 2002