--On Saturday, April 2, 2005 10:33 PM -0600 kfogel@collab.net wrote:
> Sure, understood. If that happens again, just quickly propedit the
> log message to say that you're planning to fix it up later -- that
> would be the best short-term solution, IMHO.
Note that I did exactly that: you replied to the log message change saying 'in
progress' for dist.sh. =)
I've been beaten up enough in this thread that I should at least point out
when I did exactly what you said I should have done. =(
> I always assumed we were treating dist.sh like any other piece of
> Subversion -- making master changes on trunk, and porting them outward
> to branches as necessary. Any deviation from that adds unexpected
> complexity, so IMHO it would have to be a very big benefit to be worth
> the added complexity. In this case, I'm not sure what the benefit
> would be. Why can't we just treat dist.sh normally?
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.
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.
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.
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.
> However, in the case of these *particular* changes, don't port them
> back to trunk just yet. Frankly I think the best course would be to
> revert them on the branch, then have our discussion here about what we
> want to do to dist.sh (since there is clearly some disagreement), and
> then when agreement is reached, make the appropriate changes on trunk.
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
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.)
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.
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. -- 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 08:58:27 2005