Hi Bob,
* Bob Friesenhahn wrote on Tue, Aug 14, 2007 at 01:09:37AM CEST:
>
> The reason why it is done at automake run time is that automake needs
> to generate a Makefile which includes the file in the distribution if
> it happens to exist. Makefiles are never updated by 'make dist'.
Good po
On Tue, 14 Aug 2007, Ralf Wildenhues wrote:
However, the way things are now, the check for ChangeLog is done at
automake run time, not at 'make dist' time. So, if you don't ever do
source code releases, or if you do, but you only want to invest those
10 min when releasing/release testing, we co
* Carl Fürstenberg wrote on Mon, Aug 13, 2007 at 12:53:39AM CEST:
> On 8/13/07, Robert Collins <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-08-11 at 22:06 +0200, Carl Fürstenberg wrote:
> > > On 8/11/07, Noah Slater <[EMAIL PROTECTED]> wrote:
> > > > > I think you misunderstanding me, it's the gener
On Sun, 2007-08-12 at 23:40 +0100, Noah Slater wrote:
> > I disagree. In a centralised VCS sure, you can scale to 100's of commits
> > a day - but in a distributed VCS - e.g. bzr, git, hg, monotone ... you
> > tend to get 100's of commits on branches, and a much smaller number of
> > branch merges
On 8/13/07, Robert Collins <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-08-11 at 22:06 +0200, Carl Fürstenberg wrote:
> > On 8/11/07, Noah Slater <[EMAIL PROTECTED]> wrote:
> > > > I think you misunderstanding me, it's the generation if the changelog
> > > > that will take too long time.
> > >
> > > W
> I disagree. In a centralised VCS sure, you can scale to 100's of commits
> a day - but in a distributed VCS - e.g. bzr, git, hg, monotone ... you
> tend to get 100's of commits on branches, and a much smaller number of
> branch merges occuring - branch merges being the point at which code
> revie
On Sat, 2007-08-11 at 22:06 +0200, Carl Fürstenberg wrote:
> On 8/11/07, Noah Slater <[EMAIL PROTECTED]> wrote:
> > > I think you misunderstanding me, it's the generation if the changelog
> > > that will take too long time.
> >
> > Well, yes - what else could I have understood from:
> >
> > > That
Am Samstag, den 11.08.2007, 17:33 +0100 schrieb Noah Slater:
> > The reason for this is:
> > ChangeLog: often mostly a duplicate of svn/cvs logs, seldom really used
>
> I agree about ChangeLog - there is no reason to be using this any more.
There is. Changelogs are useful to follow the changes in
en might not include
important files, like COPYING/LICENSE and README.
Thus a strictness, similar to "gnu", but without those requirements
would be preferable.
--
/Carl Fürstenberg <[EMAIL PROTECTED]>
On 8/11/07, Noah Slater <[EMAIL PROTECTED]> wrote:
> > I think you misunderstanding me, it's the generation if the changelog
> > that will take too long time.
>
> Well, yes - what else could I have understood from:
>
> > That not an optimal option, as it's illogical to store those files in the
> >
> I think you misunderstanding me, it's the generation if the changelog
> that will take too long time.
Well, yes - what else could I have understood from:
> That not an optimal option, as it's illogical to store those files in the svn.
How long does it take to generate?
--
"Creativity can be
z "$SVN2CL_EXECTUABLE"; then
> echo "Warning: Unable to find the svn2cl command."
> fi
> fi
> if test -n "$svn_directory" -a -n "$SVN2CL_EXECTUABLE"; then
> echo $SVN2CL_EXECTUABLE --authors=$AUTHORS_FILE $sv
> That not an optimal option, as it's illogical to store those files in the svn.
Well don't store them in svn - use a bootstrap script to make them
before running the autotools.
Here is the bit from my ./bootstrap that does the magic:
get_svk_svn_directory () {
# Return the SVN repository d
On 8/11/07, Noah Slater <[EMAIL PROTECTED]> wrote:
> > The problem I have with generating ChangeLog, is that it will be BIG,
> > for example, bmpx generate at the moment ChangeLog from svn log, and
> > it ends up to 2.6 MB.
>
> The common solution is to use:
>
> ChangeLog
> ChangeLog.1.gz
> ChangeL
> The problem I have with generating ChangeLog, is that it will be BIG,
> for example, bmpx generate at the moment ChangeLog from svn log, and
> it ends up to 2.6 MB.
The common solution is to use:
ChangeLog
ChangeLog.1.gz
ChangeLog.2.gz
On 8/11/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Sat, 11 Aug 2007, Noah Slater wrote:
> >
> > Of course most of us work on computers - because they make us more
> > efficient. How many emails have you sent this week - how long would
> > that have taken you with a pen and paper? (telephon
> Only projects overcome with sloth do not maintain a ChangeLog.
Why do something your self when the computer can do it for you?
That's what we invented these things for, right?
> Version control systems come and go and are often not accessible to
> everyone while the tarball may continue to exi
On Sat, 11 Aug 2007, [UTF-8] Carl Fürstenberg wrote:
In plenty of projects I have encountered, the "gnu" strictness is
toostrict, but also, the "foreign" strictness is too little
sometimes.
Thus I suggest a new strictness, somewhere in between gnu and
foreign,lets cal
> The reason for this is:
> ChangeLog: often mostly a duplicate of svn/cvs logs, seldom really used
I agree about ChangeLog - there is no reason to be using this any more.
In plenty of projects I have encountered, the "gnu" strictness is too
strict, but also, the "foreign" strictness is too little sometimes.
Thus I suggest a new strictness, somewhere in between gnu and foreign,
lets call it "relaxed", it's simlar to 'gnu
20 matches
Mail list logo
