[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 2312 - trunk/tools/client-side

From: Blair Zajac <blair_at_orcaware.com>
Date: 2002-06-25 19:38:40 CEST

Karl Fogel wrote:
>
> Blair Zajac <bzajac@demografx.com> writes:
> > > For what it's worth, i have adopted the procedure documented at
> > > <http://hackers.progeny.com/~epg/svn-3rdparty.html>. It's simple,
> > > straight-forward, and doesn't rely on any hacked-up perl scripts
> > > and their bogus automation. I'm happy with it.
> >
> > In the mean time, keep your code quality comments to yourself.
>
> Blair, Eric wasn't commenting on your coding. He was merely trying to
> say that any attempt to automate this inherently complex problem is
> going to be bogus, at least to some degree. (I suspect he's on to
> something, too; even CVS's longstanding vendor branch support requires
> human intervention.)

My sense was that by judging what Eric had to say about the automation
and the language it is written in, he didn't take a good look at what
the script does, how it runs and didn't provide any positive criticism on
how it could be improved, instead of just dismissing it.

That said, there's no automation in the script beyond what you would
expect the script to accomplish. The rename support just prints the
files and directories that exist in one but not both the svn repository
directory or the directory to be imported and let's the user match
them up so that the script can run svn mv. The script doesn't do any
renames unless the user tells it to.

Aside from the rename support, it does the deletes, copies and adds
that you would normally have to do by hand to bring a vendor branch
in the svn repository up to date with a new version, so you don't
have to worry about making any mistakes or forget to add or delete
files from svn. This looks like a pretty easy place to miss files
and have to do repeated commits to fix the tree. The script leads
to a smaller and cleaner repository with fewer commits.

>
> And there are many programmers for whom *any* Perl script
> automatically qualifies as "hacked-up"; when they apply that adjective
> to a Perl script, they're really just repeating the assertion that
> it's a Perl script. :-)

I think the problem is that if the functionality were written in C
code and in svn itself or written in Python, then it would have
gotten a different reaction.

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 19:39:27 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.