Re: [Monotone-devel] Re: Project separation
Lapo Luchini wrote: Thomas Keller wrote: I already brought up the idea on IRC some time ago - I am looking for a way to restrict allowed incoming revisions on the server-side. I've got an idea, which might well be orthogonal to yours (or be the same, really?), but could have some use: by default use the branch filter only to find the root of the graph, and then bring it all. Right now we have a (huge) graph spanning over some 30 branches but, since most of them are merged in mainline already, in fact pulling nvm-only *already* brings in the bulk of most of those branches, *except* the branch certificate. This way they're not polluting the mtn ls branches (which is good) but OTOH we're really liars about that, because we *already* have 99.9% of the bload of those branches, with the only exception of the name. We might thus (as an option, or by default) mean pull nvm as pull the ROOT element which was named 'nvm' plus all of its children, in any branch whatsoever. OTOH if some feature branches are adding huge files and then deleting them before mainline landing, we're probably *not* pulling that bulk right now; but I wonder how often does that happen in a fairly well-behaved project. Hmmm just a thought... But at work we are using 0.39 (can't use a later version as the schema changed and the latest monotone-viz just runs too slow (pre 0.40 one could use the direct access to db version of monotone-viz)). Anyway we have about 18k revisions, 10k tags and about 4k branches (guess from memory). Doing a full sync on the entire db with no changes to propagate takes about 10mins. However if you just sync the release branches (~200 branches) then that takes about 15 seconds but as Lapo says pulls in about 99% of the branches just not their certs. I know I know :-) that was 0.39 and quite frankly unless you are the build manager, why pull in all branches? But something to think about unless this has changed in the more recent versions of mtn. As I said above the choice of 0.39 is not going to change in the near future for that team but I will, just out of interest, set up my own server with 0.99.1 migrate across and then get some timing figures and post them here as this point could now be a red herring. Tony. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Project separation
Lapo Luchini l...@lapo.it writes: Thomas Keller wrote: I already brought up the idea on IRC some time ago - I am looking for a way to restrict allowed incoming revisions on the server-side. I've got an idea, which might well be orthogonal to yours (or be the same, really?), but could have some use: by default use the branch filter only to find the root of the graph, and then bring it all. Right now we have a (huge) graph spanning over some 30 branches but, since most of them are merged in mainline already, in fact pulling nvm-only *already* brings in the bulk of most of those branches, *except* the branch certificate. This way they're not polluting the mtn ls branches (which is good) but OTOH we're really liars about that, because we *already* have 99.9% of the bload of those branches, with the only exception of the name. We might thus (as an option, or by default) mean pull nvm as pull the ROOT element which was named 'nvm' plus all of its children, in any branch whatsoever. OTOH if some feature branches are adding huge files and then deleting them before mainline landing, we're probably *not* pulling that bulk right now; but I wonder how often does that happen in a fairly well-behaved project. There are branches that are not merged to mainline, and probably never will be; nvm.experimental.win32_pipes, for example. Those are children of the root of nvm, but are not pulled by nvm-only. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Project separation
Lapo Luchini wrote: CooSoft Support wrote: Hmmm just a thought... But at work we are using 0.39 (can't use a later version as the schema changed and the latest monotone-viz just runs too slow (pre 0.40 one could use the direct access to db version of monotone-viz)). I wonder how much would it take to update the direct access code; the schema has changed, but not *that* much... but you're using a pre-1.0 monotone-viz, I guess, or is direct access still in there, just not used by default? Yup pre 1.0. I remember thinking `oh great that means I won't have to recompile it again etc'... until I ran it up... :-(. Presumably all it's doing on the mtn front is a graph and then querying the revisions to get certs etc, neither of which are slow (mtn-browse can do 1000's of revisions in a few secs). Trouble is it is written in Ocaml and it is completely impenetrable, to me at least, otherwise I would have had a good look and found out what was causing the issue. I thought it might be that the mtn subprocess was restarted on each call but apparently that is not the case. Anyway we have about 18k revisions, 10k tags and about 4k branches (guess from memory). Doing a full sync on the entire db with no changes to propagate takes about 10mins. However if you just sync the release branches (~200 branches) then that takes about 15 seconds but as Lapo says pulls in about 99% of the branches just not their certs. 10 mins versus 15 seconds? Wow! 0_o I'll do some timings - remembering how long you wait for something is very subjective... Especially if you are in a hurry! Cheers :-) Tony. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Project separation
Thomas Keller wrote: I already brought up the idea on IRC some time ago - I am looking for a way to restrict allowed incoming revisions on the server-side. I've got an idea, which might well be orthogonal to yours (or be the same, really?), but could have some use: by default use the branch filter only to find the root of the graph, and then bring it all. Right now we have a (huge) graph spanning over some 30 branches but, since most of them are merged in mainline already, in fact pulling nvm-only *already* brings in the bulk of most of those branches, *except* the branch certificate. This way they're not polluting the mtn ls branches (which is good) but OTOH we're really liars about that, because we *already* have 99.9% of the bload of those branches, with the only exception of the name. We might thus (as an option, or by default) mean pull nvm as pull the ROOT element which was named 'nvm' plus all of its children, in any branch whatsoever. OTOH if some feature branches are adding huge files and then deleting them before mainline landing, we're probably *not* pulling that bulk right now; but I wonder how often does that happen in a fairly well-behaved project. -- Lapo Luchini - http://lapo.it/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
