On Sat, Apr 02, 2005 at 10:57:01PM -0800, Justin Erenkrantz wrote:
> I feel dist.sh can't be treated normally because there are branch-specific
> things that must be maintained. It's not a normal file in that sense: it
> is completely above and beyond the entire branch/trunk system - because it
> partially defines that distinction. A change to the trunk doesn't
> necessarily apply to the branch, and a change to the branch doesn't
> necessarily apply to the trunk.
In the past year of maintaining this file there has been exactly *ONE*
difference that had to be expliclity maintained and not merged from
trunk to the branch and that's the difference between the book URL.
This seems like a pretty minor difference. I don't really anticipate
there being more differences in the future. I have intentionally made
an effort to avoid such differences and make dist.sh identical
otherwise.
> Therefore, I believe that dist.sh should internally handle differences
> between branch (i.e. keep one master copy that does different things based
> on the -version flag) as multiple copies of this file just creates
> unnecessary confusion.
That's actually probably not a bad way of removing the one difference we
currently have with the book URL. If we did this then there wouldn't be
any difference. But I'm not sure the complexity of this is worth it and
unfortunately the book URLs have changed a lot lately.
I guess this really depends on if the book authors are going to commit
to having a new version of the book ready simultaneously with a new
branch release. From past experience I don't think we will have this.
But I'll let them speak for themselves as to if they can do that.
> Then, I would either yank dist.sh out of trunk and move dist.sh into a
> separate directory (i.e. /releases), or keep dist.sh and remove all copies
> of dist.sh from the branches/ directories.
>
> But, no, dist.sh is absolutely not a normal file. IMHO, having multiple
> copies of this file just creates unnecessary confusion.
Huh? I don't see what's confusing about this. dist.sh isn't any
different than say CHANGES. We maintain multiple copies of this file.
The original modifications are made to CHANGES and then merged onto the
proper branch.
How I've handled dist.sh is I did all work on it on trunk and then when
a release came along I ran log and reviewed all the changes made to it
since the last merge onto that branch and decided what needed to be
merged. This usually took all of 5 mins per release, with often being
minimal if any changes between releases.
> I believe part of the reason people got upset is that I committed the
> changes to the branches/1.1.x - yet, from my perspective as someone who is
> rolling a 1.1.x release not a trunk release, changes to trunk/ didn't make
> any sense.
Well CHANGES is maintained on trunk too. I don't really see the huge
difference here. Any enhancements you want to make to dist.sh probably
are useful to future releases. You could do it the other way around and
work on a branch and move things back to trunk. But it's completely
backwards from anything else we do. It's much easier to say "all
development happens on trunk" and "changes that make it into release
branches are ported from trunk."
I think you're completely overstating the differences between the
dist.sh for trunk and the dist.sh for 1.1.x. In fact the only
difference probably was that one change that I don't like and intended
to revert but just hadn't yet...
> Here's what I did:
>
> - I reverted the changes entirely from branches/1.1.x.
> - I applied those changes that I feel are not controversial to trunk.
> (adding support for curl, PGP, etc.)
>
> I did *not* commit the following to trunk:
> - -apr* rename
> - use of svn export to fetch dependencies
Thank you.
> There was a pre-existing use of svn export that I don't really understand;
> I think breser is against it, but since I have no idea what that's for or
> who put it there, I left it there. Someone else can yank it out, if they
> like. (You'd only have to remove it once instead of four times after the
> function refactoring.)
It allows you to have an existing svn wc and point the dependency paths
to that wc and then it detects that it is a svn wc and runs an export.
I'm even more against this as it might allow someone to accidentally
ship local modifcations without realizing it.
Prior to the change that added this we handled removing CVS and
.cvsignore which in effect made the same thing work for CVS. I never
really thought of that as being an export but the net effect was the
same and I guess people used it for that. I always viewed that code as
just being paranoid to make sure CVS stuff didn't end up in our tarball.
Not having been around when that was originally added I have no idea
what the intent was.
At least your change runs export against the URL and can't accidentally
get local mods in the tarball.
> As for the -apr* options rename, I think the arguments against changing the
> prefix are non-sensical. In fact, by introducing a *different* acronym
> than what the APR project uses itself, it only makes it way more
> complicated than it needs to be. I still believe this is a good change and
> should be made eventually.
I don't think it's terribly complicated to remember that apr-util is
apru and apr-iconv is apri, IMHO apu and api are non-sensical
abbreviations considering that api is completely ambiguous with a common
computer term.
Further, it's not like APR is even consistent. The lib is libaprutil,
they've got some files named apu_*, some files named apr_* and a some
files without any prefix whatsoever. And the directory is named
apr-util as is some references refer to it that way through the code.
Basically, I don't think the vast majority of people have a clue that
apu is the acronym that the APR project uses for apr-util other than APR
project people. If you're not a developer and you don't look at the
source the one and only place you would see apu is apu-config, which if
you're not a developer you're probably not going to notice anyway.
> As for the 'svn export' option, I think it is a worthy option to allow
> people to build custom tarballs without going through undue hassle.
Well I think everyone knows how I feel about that.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 12:41:40 2005