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

Re: svn commit: r13838 - branches/1.1.x

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2005-04-03 03:44:49 CEST

--On Saturday, April 2, 2005 4:26 PM -0800 Ben Reser <ben@reser.org> wrote:

> a) This is a feature... When we add features we have to way the
> benefits, costs, and if it's even really useful. We have tried to shy
> away from implementing features that are highly specialized to a
> particlar group of people or that nobody has really ever asked for or
> can come up with a use case for.
>
> Granted, I know of some use cases for this, but they are rare. I can
> think of all of 4 people that I'm aware of that have ever run dist.sh
> recently. And none of them have ever had a problem getting
> dependencies.

Might not their jobs be easier if there was another way? I'd would like to
reduce the complexity required by the person running the dist.sh script to
make it easier to roll a tarball (be it for random use or for public
distribution).

> b) We also have to look at the alternatives to the feature. What could
> we do that might be better.

The 'svn export' is a solution that allows the dependencies to bundle the
dependencies without having them downloaded previously. To be clear, in IRC
on Friday, I had suggested that dist.sh have the option to fetch the release
tarballs from the site and allow the RM to confirm the dependency signatures
manually before proceeding. But, you said that you would veto that as well
even if I wrote that functionality.

> I still think if we want to make it easier to produce a quick snapshot
> tarball we make dist.sh capable of simply ignoring the depencies. Our
> build system has no problem with this and it would be insanely simple to
> do in dist.sh

Yes, I agree that could be goodness as well. (i.e. -nodeps flag to dist.sh?)

> c) We have to look at the drawbacks. In this particular case the vast
> majority of the use of it is to produce our own tarball. If this
> feature is used to produce the tarball it could be really bad. I'm not
> going to harp on why again.

And, as I've said, I don't think that's a major issue.

> Wouldn't it lessen the overhead even more just by removing the need to
> include the dependencies? We include them to lessen the burden on our
> users downloading the tarball. But as far as I know most of the use
> cases of dist.sh outside of our uses don't care about these dependencies
> and only deal with them because dist.sh requires them.

In the cases where I was creating snapshots, I was creating them for folks who
didn't have the dependencies either (i.e. an OS with just a compiler that
needed some SVN patches that weren't in a SVN release just yet). -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 03:46:05 2005

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.