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

Re: svn commit: propchange - r13838 - svn:log

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2005-04-03 08:57:01 CEST

--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

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