--On Sunday, April 3, 2005 3:40 AM -0700 Ben Reser <ben@reser.org> wrote:
> 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.
That is not true. The trunk had the 'svn export' of the dependencies, while
the branches/ didn't have that. So, there are more differences than just the
book URL. I'd prefer that we just eliminate the option of having any
discrepancies at all and remove dist.sh from the branches.
> 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'm just saying that shouldn't be necessary if we only keep one version of
dist.sh.
> 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.
Ah, right.
> 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.
Well, those are the acronyms used by APR. In my opinion, there is no
legitimate need to differ here.
> 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.
The canonical file is apu.h and apu_version.h here.
> 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.
Well, the issue is that there *is* significant overlap between APR developers
and Subversion developers. So, I am very aware of what APR-util, APR-iconv
call themselves officially. And, it's annoying to me that Subversion chooses
to pick random acronyms.
At the very least, it should be expanded out to -apr-util and -apr-iconv if
you veto -apu and -api. But, -apru and -apri mean nothing to anyone. How
would we feel if someone chose 'svnv' for Subversion because they don't like
'svn' as an acronym? -- 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 18:54:04 2005