Koen Kooi schrieb:
I'm trying to make a ChangeLog or NEWS style overview[1] of the changes in my
repo, but I
can't find an easy way (trivially parseable by shell scripts) to get the first
line(s) of
a commit message.
The gist of the problem:
'automate cert REVISION-ID NAME VALUE' should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm trying to make a ChangeLog or NEWS style overview[1] of the changes in my
repo, but I
can't find an easy way (trivially parseable by shell scripts) to get the first
line(s) of
a commit message.
The gist of the problem:
'automate cert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Keller schreef:
Koen Kooi schrieb:
I'm trying to make a ChangeLog or NEWS style overview[1] of the
changes in my repo, but I
can't find an easy way (trivially parseable by shell scripts) to get
the first line(s) of
a commit message.
The
Nathaniel Smith, 2007-05-30:
In my world, the reason we need partial pull is that the total history
size of a project grows without bound. Therefore, for very large and
old projects (Linux kernel, *BSD, Mozilla, gcc, glibc, maybe a few
others), the full history database may be many times
On Fri, 2007-06-01 at 12:00 +0200, Koen Kooi wrote:
[...]
Many thanks! The result:
http://www.openembedded.org/repo/org.openembedded.dev/contrib/mtn2cl/mtn2cl.sh
...
That script really ought to be more careful about how it removes its
temporary files.
rm `ls | grep -v ChangeLog | grep -v
Hi,
Christian Ohler wrote:
This looks like two separate issues to me:
(1) The total history size of a project in monotone grows without bound.
(2) The time it takes for a new developer to get a local workspace of a
project is too high with monotone.
As far as I can tell, problem (1) on its
Hey kiddy ;-)
You have removed the options --xargs, --quiet, --norc, --nostd and some
others from monotone.texi?
I'm totaly missing all these nice options in the manual (monotine.pdf).
Removed on revision 2adc287d1d2beff5ec8804415469d23ec2ee7110 at
2006-08-05T03:28:14
The file 'mtn.1' is
On 6/1/07, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Basically, what I'm stating is, that the avg. history vs. checkout size
ratio probably is that low, because the tools to track history were
lacking. I bet that this ration will grow, as soon as people learn about
the benefits of properly
Markus Schiltknecht wrote:
Hm.. merging branches with need a flag day serves the purpose of
reducing the amounts of flag days needed for end-users. Why would you
want to have multiple flag day branches?
To keep the various things that might be considered for a flag day
logically separated. I'm
