In message <[EMAIL PROTECTED]> on Tue, 22 May 2007 23:12:45 +0200, "Benoît
Dejean" <[EMAIL PROTECTED]> said:
benoit> I have a repository of 2000 files over NFS. update and status
benoit> are very slow. I have strace/truss it and found a lot of stat
benoit> calls. I think this just kill performanc
On 5/22/07, Brian May <[EMAIL PROTECTED]> wrote:
> "J" == J Decker writes:
J> mtn --db=test.db db init
J> mtn --db=test.db genkey temp
J> mtn --db=test.db --key=temp --branch=branch1 setup .
J> echo "Branch1" >file
J> mtn --db=test.db --key=temp add file
J> mtn -
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 heuristic
Hello,
I have a repository of 2000 files over NFS. update and status are very
slow. I have strace/truss it and found a lot of stat calls. I think this
just kill performance on a network filesystem. When doing a status, each
file is stat'ed 4 times in a row. The following patch saves 2 calls. The
1
> "J" == J Decker writes:
J> mtn --db=test.db db init
J> mtn --db=test.db genkey temp
J> mtn --db=test.db --key=temp --branch=branch1 setup .
J> echo "Branch1" >file
J> mtn --db=test.db --key=temp add file
J> mtn --db=test.db --key=temp commit -m "Begin branch1"
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 (
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 Lin
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
> >>> consult the Monotone developers wit
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 rebuilt/rewrit
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" == 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 g
> "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,
On Tue, 2007-05-22 at 18:40 +0200, Benoît Dejean wrote:
> Hello everyone,
>
> On my Debian sid, the auto* fail to link mtn :
>
[...]
>
> So it's missing boost_unit_test_framework. Moreover it's linking with
> the MT version of boost where the st are available. A manual link like
> the following
On Tue, May 22, 2007 at 10:16:01PM +1000, William Uther wrote:
>Option ii) I could start a new branch for my own version of the code,
> develop on the main branch, and propagate the changes across. This means I
> don't get to develop with my local changes (which is both a positive and a
>
It is easy to set up.
I have a project hosted here: http://www.fortasoft.org/project/browser that
you can use to take a look since the TracMonotone site is down.
Some things don't work but you can easily and reliably browse the head of
any branch with syntax highlighting, which is good enough f
Actually I run into your option 1 problem fairly often, particularly with
configuration files.
The solution that would be most helpful to me is actually pretty simple:
If there was a ".mtn-ignore-commit" file that prevented matched files from
being committed, I think that would eliminate most of
Eduardo Morras <[EMAIL PROTECTED]> wrote:
> I'm a newbie and before to install, want to know if monotone has a
> tracking system as CVSTrac or Trac for CVS.
Yes. There is a Monotone plugin for Trac written by Thomas Moschny
<[EMAIL PROTECTED]>. You can find it on the
net.venge.monotone.trac-plu
Hello everyone,
On my Debian sid, the auto* fail to link mtn :
g++ -DNDEBUG -DBOOST_DISABLE_THREADS -DBOOST_SP_DISABLE_THREADS
-DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -g -O2 -Wall -W -Wno-unused
-fno-strict-aliasing -o mtn mtn-sanity.o mtn-simplestring_xform.o
[...]
mtn-schema.o lib3rdpar
Hello:
I'm a newbie and before to install, want to know if monotone has a tracking
system as CVSTrac or Trac for CVS.
I come from CVS plus CVSTrac system and work with FreeBSD6.
Thanks in Advance
Alien.org contacted...waiting f
Hi all,
I thought I'd throw out another wacky idea... I've been mulling
this one for a while, but a post by Stéphane Gimenez in the Branches
in git and monotone was close enough that I thought I'd bring it up...
There are a number of situations where I have local patches to a
program
On 5/22/07, Nathaniel Smith <[EMAIL PROTECTED]> wrote:
On Tue, May 22, 2007 at 01:35:44AM -0700, J Decker wrote:
>It would be really nice if the current branch tag in _MTN/options
would
>update even if the revision is already up to date.
What version of mtn are you using? I thought thi
On 5/22/07, Richard Levitte <[EMAIL PROTECTED]> wrote:
What you're missing in the whole thing is the ancestry. You see, with
your last commit (which is to branch1), you're using the previous
commit (which is in branch2) as ancestor, so even if you're not doing
a propagate, you are producing a h
On Tue, May 22, 2007 at 01:35:44AM -0700, J Decker wrote:
>It would be really nice if the current branch tag in _MTN/options would
>update even if the revision is already up to date.
What version of mtn are you using? I thought this bug was fixed
already...
-- Nathaniel
--
So let us es
What you're missing in the whole thing is the ancestry. You see, with
your last commit (which is to branch1), you're using the previous
commit (which is in branch2) as ancestor, so even if you're not doing
a propagate, you are producing a history that goes back and forth
between the branches.
To
Okay - Along this same topic. This is very very very annoying.
So I got all done, branch.test was up to date with branch. and vice versa.
(current workspace is on branch.test)
mtn update -r h:branch
mtn.EXE: expanding selection 'h:[branch]'
mtn.EXE: expanded to '908a782fdccba6caea8ccf06416a9
I was doing some work, and decided that I wanted to commit that work to a
new branch, so as to not distrub other developers too badly... I still
haven't completely tested the changes, but it turns out that the changes
were included in the main branch anyhow because I then made some other
changes t
26 matches
Mail list logo
