Justin Erenkrantz <justin@erenkrantz.com> writes:
> 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. =(
Nice try, but... C'mon :-). That log message wasn't clear at all.
What exactly was "in progress"? The changes to dist.sh? The log
message itself? The two words "in progress" give absolutely no
indication that you're planning to come back and do something later.
If you really put yourself in the shoes of some random developer
reviewing that commit, I think you have to admit the log message
didn't convey much. It certainly didn't give any indication that you
were planning to come back and edit it later -- I mean, I read it and
came away with no such impression.
Btw, you're not getting beaten up, sorry if you feel you are. People
are raising technical objections to both some changes you made, and to
a branch/trunk methodology you wanted to introduce for dist.sh.
Happens all the time; heck, it's happened to me on many issues
(remember the whole STATUS file vs issue tracker thing way back when?).
> 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
Thanks.
> 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.)
That's for grabbing Subversion itself, if I recall correctly. I think
I wrote it a long time ago; but if you guys want to use some other
method, I certainly have no objection in principle. Whatever works.
> 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.
If you and Ben Reser both feel that way, then I withdraw my objection
to the "-api" flag. I see your point about how different from APR is
a cost in itself.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 15:24:26 2005