On Tue, May 22, 2007 at 08:19:33PM -0600, Derek Scherger wrote:
In terms of performance, I did a very quick test today on a ~30,000 file
tree and git status took ~0.6 seconds while monotone (with inodeprints
on) took ~3.5 seconds. Personally, ~3.5 seconds doesn't really offend me
and I'm
On Mon, May 28, 2007 at 09:03:21PM -0600, Derek Scherger wrote:
However the project policy stuff works out I certainly hope that a
similar branch life-cycle will be possible. I actually wonder if this is
where we should be starting with the policy stuff, since it's a feature
that everyone
On Mon, May 21, 2007 at 09:25:24AM -0400, Jack Lloyd wrote:
I wouldn't think so, RSA verification is pretty cheap.
Also, you mostly don't have to even do it -- it turns out the
interesting operations are things like heads, where you just need to
know the most recent valid signatures with some
Nathaniel Smith [EMAIL PROTECTED] writes:
[...]
Eek, we should fix that. (And 0.6s vs. 3.5s is the difference between
instant and twiddle-twiddle-twiddle in user experience terms.)
We have no excuse for going 6 times slower on status; we should be
(and at some point were) fast-pathing
On Tue, May 29, 2007 at 01:21:49PM +0100, Bruce Stephens wrote:
Nathaniel Smith [EMAIL PROTECTED] writes:
Eek, we should fix that. (And 0.6s vs. 3.5s is the difference between
instant and twiddle-twiddle-twiddle in user experience terms.)
We have no excuse for going 6 times slower on
Brian May [EMAIL PROTECTED] writes:
[...]
As there any references on how policy branches will solve these
problems?
No. It hasn't been designed yet. There are some candidate ideas on
the wiki.
Some bits are easy: for internal purposes, branches are an identifier
(probably a hash), and the
Le mardi 29 mai 2007 à 05:26 -0700, Nathaniel Smith a écrit :
On Tue, May 29, 2007 at 01:21:49PM +0100, Bruce Stephens wrote:
Taking 3.5s to stat Derek's directory tree is a straight bug too, is
my point.
I have experienced the same behaviour with a 10K files repository. mtn
status was 6x
Le mardi 29 mai 2007 à 13:34 +0100, Bruce Stephens a écrit :
Nathaniel Smith [EMAIL PROTECTED] writes:
[...]
Taking 3.5s to stat Derek's directory tree is a straight bug too, is
my point.
Oh, yes. At least for an unchanged tree, there's no reason monotone
has to be slower than git
Brian May wrote:
As there any references on how policy branches will solve these
problems?
Whatever exists is on the wiki but I'm not sure whether there's a nice
list of requirements or anything.
The *one* nice thing about subversion branches is that they have a
life-cycle. You can create a
Bruce == Bruce Stephens [EMAIL PROTECTED] writes:
Bruce I'm not particularly bothered about keeping redundant work
Bruce (which in git could vanish); I am worried about ending up
Bruce with zillions of branches which have names we no longer
Bruce like and which were only of
Graydon Hoare [EMAIL PROTECTED] writes:
Thomas Moschny wrote:
Having combined certs would solve that problem at the cost of
sometimes storing the same information twice: e.g. when two people
do the same merge, there will be two certs with different
dates/authors, but identical branch names
Derek Scherger [EMAIL PROTECTED] writes:
[...]
The ui/command-set in git seems complicated and somewhat strange though.
For example the fact that pull does fetch+merge seems a bit odd coming
from monotone. It almost seems like fetch should have been called
pull and merge could have been
On Wednesday 23 May 2007, Richard Levitte wrote:
In message [EMAIL PROTECTED] on Wed, 23 May 2007 09:51:03
+1000, Brian May [EMAIL PROTECTED] said:
bam Bruce == Bruce Stephens [EMAIL PROTECTED]
writes: bam
bam Bruce Probably more of a win to have a combined
bam Bruce
Derek Scherger wrote:
Anyway, I should play around with it some more, it does seem reasonable
and there's nothing wrong with fast!
A wise man once said: Premature optimization is the root of all evil.
And I pretty much agree with that. Give me a program that works, rather
than one that is
Thomas Moschny wrote:
Having combined certs would solve that problem at the cost of sometimes
storing the same information twice: e.g. when two people do the same merge,
there will be two certs with different dates/authors, but identical branch
names and commit messages. But that's reasonable
Ulf Ochsenfahrt wrote:
A wise man once said: Premature optimization is the root of all evil.
It was Tony Hoare, though Knuth popularized it. See:
http://www.acm.org/ubiquity/views/v7i24_fallacy.html
--
__
\/ o\ Paul Crowley, [EMAIL PROTECTED]
/\__/ http://www.ciphergoth.org/
Paul Crowley wrote:
Ulf Ochsenfahrt wrote:
A wise man once said: Premature optimization is the root of all
evil.
It was Tony Hoare, though Knuth popularized it. See:
http://www.acm.org/ubiquity/views/v7i24_fallacy.html
Interesting. I didn't mean to start a flamewar, I just meant to
Ulf Ochsenfahrt wrote:
Interesting. I didn't mean to start a flamewar, I just meant to support
Graydon's previous post
I was linking to that essay mainly to provide a cite for the Hoare
quote! There's plenty to disagree with in it, such as the idea that
learning assembly language has much
Graydon Hoare wrote:
In practice it's heuristic, same as the movement inference heuristics
in mercurial. This is the road we initially went down. We eventually
gave up. The misery is archived in the history of a dead file called
change_set.cc if you go looking for it (and patch_set.cc before
On Wed, May 23, 2007 at 10:01:12PM -0600, Derek Scherger wrote:
[..] but I wonder if it would simplify things and maybe help speed
things up a bit more. Food for thought if nothing else.
Sure, it might. But still, let's start for speed by looking at the
string and memory copying in roster
On Wed, May 23, 2007 at 11:14:24AM +0200, Ulf Ochsenfahrt wrote:
Graydon == Graydon Hoare [EMAIL PROTECTED] writes:
Maybe I'm a bit of a wuss.
No, Graydon, you're not.
.. or if you are, you're exactly the right kind of wuss.
--
Dan.
pgpV1Fw3hRZ04.pgp
Description: PGP signature
Graydon == Graydon Hoare [EMAIL PROTECTED] writes:
Graydon Nuno Lucas wrote:
Maybe I got this wrong, but based on what I have seen so far
of this talk, I couldn't help but think that Linus didn't
consult the Monotone developers with his concerns about speed,
why it was
Bruce == Bruce Stephens [EMAIL PROTECTED] writes:
Bruce Probably more of a win to have a combined
Bruce date+author+branch+changelog kind of cert thing (since
Bruce that's what you want on almost all revisions) such as has
Bruce been suggested before.
That would be good.
Having
On 5/22/07, Brian May [EMAIL PROTECTED] wrote:
Bruce == Bruce Stephens [EMAIL PROTECTED] writes:
Bruce Probably more of a win to have a combined
Bruce date+author+branch+changelog kind of cert thing (since
Bruce that's what you want on almost all revisions) such as has
Bruce
Justin Patrin wrote:
Signer and author are different things. I can sign something but set
you as the author if I wished. This is often used (in OpenEmbedded) to
commit patches for people who don't have push access to a server.
It has also been used in the past when history was
On 5/22/07, Derek Scherger [EMAIL PROTECTED] wrote:
Brian May wrote:
Graydon == Graydon Hoare [EMAIL PROTECTED] writes:
Graydon Nuno Lucas wrote:
Maybe I got this wrong, but based on what I have seen so far
of this talk, I couldn't help but think that Linus didn't
In message [EMAIL PROTECTED] on Wed, 23 May 2007 09:51:03 +1000, Brian May
[EMAIL PROTECTED] said:
bam Bruce == Bruce Stephens [EMAIL PROTECTED] writes:
bam
bam Bruce Probably more of a win to have a combined
bam Bruce date+author+branch+changelog kind of cert thing (since
bam
Justin Patrin wrote:
One thing
Linus mentions in the talk is that a function moving from one file to
another would be recognized by annotate because of the fact/way that git
tracks content. This sounds interesting and I'm curious as to what it
looks like in practice.
In practice it's
Brian May [EMAIL PROTECTED] writes:
J == J Decker J writes:
J Harsh (also beware of falling rants) Unforutnatly,
J although monotone has become much much better for performance
J issues... it was knocked out of the world of 'valid'
J distributed version control systems
On Mon, May 21, 2007 at 01:21:11PM +0100, Bruce Stephens wrote:
Just doing update, monotone checks RSA signatures (to see if
revisions are on the branch), calls lua hooks (for the same reason);
and throughout all that gets its information from SQLite. (At that
time, IIRC, base64 encoded
On Mon, May 21, 2007 at 03:04:29PM +0100, Bruce Stephens wrote:
Ah, there isn't a revision cert. Revisions just are.
Oh, oops! put_simple_revision_cert and cert_revision_in_branch in
cert.cc threw me off. Obviously I understand Montone's schema even
less than I thought I did. Thanks for the
On 21/05/2007, at 14:47, Jack Lloyd wrote:
On Mon, May 21, 2007 at 01:21:11PM +0100, Bruce Stephens wrote:
Just doing update, monotone checks RSA signatures (to see if
revisions are on the branch), calls lua hooks (for the same reason);
and throughout all that gets its information from
Nuno Lucas wrote:
Maybe I got this wrong, but based on what I have seen so far of this
talk, I couldn't help but think that Linus didn't consult the Monotone
developers with his concerns about speed, why it was slow, or how much
work it would take to improve its speed.
He talked to us a bit.
33 matches
Mail list logo
