Re: [Monotone-devel] Re: nvm.stripped

Derek Scherger schrieb: > On Sun, Oct 12, 2008 at 2:49 PM, Zack Weinberg <[EMAIL PROTECTED] > > wrote: > > I put some patches on .library-build to deal with this. The 'best > effort' functionality is not available in 1.5 as far as I know, but I > don't know an

Re: [Monotone-devel] advice, please, on organising branches

On Sun, Oct 12, 2008 at 06:58:52PM -0700, Zack Weinberg wrote: > On Mon, Oct 13, 2008 at 12:04 AM, <[EMAIL PROTECTED]> wrote: > > I'm working on in a compiler that will at some time have multiple code > > generators. These will target different so-called machine-independent > > intermediate codes

Re: [Monotone-devel] set verses vector in args_to_paths

On Sun, Oct 12, 2008 at 6:28 PM, Zack Weinberg <[EMAIL PROTECTED]> wrote: The only thing I'd be worried about is making sure we're not doing a > std::set copy now (which is more expensive than a std::vector copy). > Restriction objects tend to be on the stack so maybe they don't need > to copy (co

Re: [Monotone-devel] advice, please, on organising branches

On Mon, Oct 13, 2008 at 12:04 AM, <[EMAIL PROTECTED]> wrote: > I'm working on in a compiler that will at some time have multiple code > generators. These will target different so-called machine-independent > intermediate codes, and will be appropriate in different execution > environments. > > Th

[Monotone-devel] advice, please, on organising branches

I'm working on in a compiler that will at some time have multiple code generators. These will target different so-called machine-independent intermediate codes, and will be appropriate in different execution environments. The obvious way to organise this is as a tree of branches A

Re: [Monotone-devel] mtn db check

Timothy Brownawell wrote: "missing manifests that are referenced by their sha1 hash from some revision but do not exist in the database." ... We used to store these, but switched to storing "rosters" instead. These are like manifests, but they also include various cached values that speed up me

Re: [Monotone-devel] set verses vector in args_to_paths

On Sun, Oct 12, 2008 at 5:20 PM, Derek Scherger <[EMAIL PROTECTED]> wrote: > When I was fiddling with the include/exclude stuff I noticed that > args_to_paths returns a vector of paths which is used almost exclusively in > calls to restriction constructors. "It was that way when I got here." :-)

[Monotone-devel] set verses vector in args_to_paths

When I was fiddling with the include/exclude stuff I noticed that args_to_paths returns a vector of paths which is used almost exclusively in calls to restriction constructors. These quickly turn the vectors into sets of paths and I wondered whether it would be better if everything just worked in t

Re: [Monotone-devel] new include/exclude commands?

On Sun, Oct 12, 2008 at 3:32 PM, Thomas Keller <[EMAIL PROTECTED]> wrote: > Derek Scherger schrieb: > > Since 0.40 there is a new hook `get_default_command_options` which could > > > > > > Hrm, I hadn't used that before, but it does seem nice. Was it added just > > after 0.40 or is it included in

Re: [Monotone-devel] Re: nvm.stripped

On Sun, Oct 12, 2008 at 2:49 PM, Zack Weinberg <[EMAIL PROTECTED]> wrote: > I put some patches on .library-build to deal with this. The 'best > effort' functionality is not available in 1.5 as far as I know, but I > don't know any reason why the //TRANSLIT//IGNORE thing that we had > before the '

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

On Sun, Oct 12, 2008 at 06:26:52PM -0400, Jack Lloyd wrote: > On Sun, Oct 12, 2008 at 03:48:25PM -0500, Timothy Brownawell wrote: > > > Unrelated thought: would it make sense for mtn version --full to print > > > out the version #s of the various libraries, since they are no longer > > > fixed by t

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

On Sun, Oct 12, 2008 at 03:48:25PM -0500, Timothy Brownawell wrote: > > Unrelated thought: would it make sense for mtn version --full to print > > out the version #s of the various libraries, since they are no longer > > fixed by the monotone version? > > Sounds like a good idea. I've attached a

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

On Sun, Oct 12, 2008 at 03:48:25PM -0500, Timothy Brownawell wrote: > On Sun, 2008-10-12 at 15:34 -0400, Jack Lloyd wrote: > > I built nvm.stripped b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1 against > > SQlite 3.5.9, Botan n.r.botan head, PCRE 7.7, Lua 5.1.3 on my > > Gentoo/Core2 box, GCC 4.3.2. mak

Re: [Monotone-devel] mtn db check

On Sun, 2008-10-12 at 19:33 +0200, Daniel Carrera wrote: > Hello, > > I'm reading the documentation of mtn db check. It says that, among other > things, this command will detect the following problem: > > "missing manifests that are referenced by their sha1 hash from some > revision but do not

Re: [Monotone-devel] new include/exclude commands?

Derek Scherger schrieb: > Since 0.40 there is a new hook `get_default_command_options` which could > > > Hrm, I hadn't used that before, but it does seem nice. Was it added just > after 0.40 or is it included in 0.40? (my system installed 0.40 doesn't > seem to have it but more recent builds do)

Re: [Monotone-devel] new include/exclude commands?

"Derek Scherger" <[EMAIL PROTECTED]> writes: > Was it added just after 0.40 or is it included in 0.40? (my system > installed 0.40 doesn't seem to have it but more recent builds do) I think we should bump the version number in the sources immediately _after_ a release, just to avoid this kind of

Re: [Monotone-devel] new include/exclude commands?

"Derek Scherger" <[EMAIL PROTECTED]> writes: > This change isn't about ignoring unversioned files but about temporarily > ignoring changes to versioned files. I.e. restricting > status/diff/commit/etc. to specified sets of files, which is already > possible with command line path arguments. This j

Re: [Monotone-devel] Re: nvm.stripped

On Sat, Oct 11, 2008 at 9:28 PM, Derek Scherger <[EMAIL PROTECTED]> wrote: > I'm now looking at idna (libidn) which ought to be easy but isn't because of > some changes that were made at the 2007 summit iirc. Lapo, do you recall the > "best effort" stuff that got added to idna/toutf8.c? This is not

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

On Sun, 2008-10-12 at 15:34 -0400, Jack Lloyd wrote: > I built nvm.stripped b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1 against > SQlite 3.5.9, Botan n.r.botan head, PCRE 7.7, Lua 5.1.3 on my > Gentoo/Core2 box, GCC 4.3.2. make check had two failures: > > 192 empty_environment

Re: [Monotone-devel] new include/exclude commands?

On Sun, Oct 12, 2008 at 11:54 AM, Thomas Keller <[EMAIL PROTECTED]> wrote: > > The question is probably where and how long these things should persist. My expectation is that they would be relatively transient. One use-case is selecting things I'm preparing to commit by looking at status and dif

Re: [Monotone-devel] Re: nvm.stripped

On Sun, Oct 12, 2008 at 10:13 AM, Jack Lloyd <[EMAIL PROTECTED]> wrote: > Two things on nvm.stripped (rev b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1) > > I am warned: > > Makefile.am:339: whitespace following trailing backslash > > There is a trailing tab on that line. > > Also, here is the output c

Re: [Monotone-devel] new include/exclude commands?

Derek Scherger schrieb: > I had an idea the other day, where I was continually having to provide a > bunch of --exclude optons in a workspace with some (intentionally) missing > files, that it might be useful to be able to specify a set of includes or > excludes that persist across several commands

[Monotone-devel] mtn db check

Hello, I'm reading the documentation of mtn db check. It says that, among other things, this command will detect the following problem: "missing manifests that are referenced by their sha1 hash from some revision but do not exist in the database." My question: What is a manifest? Daniel.

Re: [Monotone-devel] Re: nvm.stripped

On Sun, Oct 12, 2008 at 09:53:34AM -0600, Derek Scherger wrote: > Heh, just noticed that too. I've merged and pushed so things are good. I > removed -DTEMP_STORE from AM_CFLAGS in Makefile.am in the merged version. As > near as I can tell this was only relevant for SQLITE. Two things on nvm.strip

Re: [Monotone-devel] db kill_rev_locally

Daniel Carrera spake unto us the following wisdom: > Thanks. I believe I understand the technique now. Make a dummy account > where all the devs login and give them a shell that does nothing. It's > very good, and it seems to work in every case in which my initial > proposal works. It'd be ni

Re: [Monotone-devel] new include/exclude commands?

On Sun, Oct 12, 2008 at 3:31 AM, Brian May <[EMAIL PROTECTED]>wrote: > Derek Scherger wrote: > >> I had an idea the other day, where I was continually having to provide a >> bunch of --exclude optons in a workspace with some (intentionally) missing >> files, that it might be useful to be able to s

Re: [Monotone-devel] Re: nvm.stripped

On Sun, Oct 12, 2008 at 7:31 AM, Markus Wanner <[EMAIL PROTECTED]> wrote: > > > and also moved sqlite to the Attic > > ..oops, looks like we've done duplicate work. I've just committed and > pushed what I have. It's not quite complete, yet (rev > 4c625e162bf17c69406de23482187313dafd29cd). Have you

Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?

Hi, Ralf S. Engelschall wrote: > Ok, I finally found time to finish the preparation of the SQLite > upgrade. Sorry for the delay, I was heavily busy because of my day job. > I've pushed the following two branches to monotone.ca today: > > o net.venge.monotone.rse.sqlite-upgrade > ... > o net.veng

Re: [Monotone-devel] Re: nvm.stripped

Hi, Derek Scherger wrote: > I've made this change Cool, thanks. > and also moved sqlite to the Attic ..oops, looks like we've done duplicate work. I've just committed and pushed what I have. It's not quite complete, yet (rev 4c625e162bf17c69406de23482187313dafd29cd). Have you pushed your work,

Re: [Monotone-devel] db kill_rev_locally

Ludovic Brenta wrote: Which would require me to have SSH login ("daniel"). What am I missing? You are correct but the [EMAIL PROTECTED] account may be unprivileged (running a restricted shell) and shared with other developers. You might as well call it after the project the developers work on,

Re: [Monotone-devel] Re: Undo a commit

Brian May schrieb: > Thomas Keller wrote: >> I'd do it "safely" without messing around with _MTN/revision and move >> the current changes aside to re-apply them later on: >> >> $ mtn diff > current_changes.txt >> $ mtn revert . >> $ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597 >

Re: [Monotone-devel] new include/exclude commands?

Derek Scherger wrote: I had an idea the other day, where I was continually having to provide a bunch of --exclude optons in a workspace with some (intentionally) missing files, that it might be useful to be able to specify a set of includes or excludes that persist across several commands. This

Re: [Monotone-devel] Re: Undo a commit

Thomas Keller wrote: I'd do it "safely" without messing around with _MTN/revision and move the current changes aside to re-apply them later on: $ mtn diff > current_changes.txt $ mtn revert . $ mtn db kill_rev_locally dcfbf59823cf21e292b60ba8f8463f65ea383597 $ patch -p0 < current_changes.txt

Re: [Monotone-devel] db kill_rev_locally

Daniel Carrera writes: > Ethan Blanton wrote: >> Then, to connect to the server, run something like the following on >> your workstation: >> >> ssh -L4691:localhost:4691 > > Could you clarify this command? My reading of it is: > > ssh -L4691:localhost:4691 [EMAIL PROTECTED] > > > Which would r