Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict

Stephen Leake spake unto us the following wisdom: > > As a concrete example, the Pidgin project, for historical reasons and > > as a position that I will admit not everyone agrees with, has a single > > repository containing 1) libpurple, a library implementing the guts of > > an instant messaging

Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict

Stephen Leake spake unto us the following wisdom: > Markus Wanner writes: > > However, another perfectly valid use case is wanting to permanently > > delete a file in a child branch, which might continue to get modified in > > the parent branch. You'd not want that to conflict every time you > > p

Re: [Monotone-devel] Re: removal of packet functions

Stephen Leake spake unto us the following wisdom: > 2) netsync via file: to a mtn db on a USB drive, physically transport >the USB drive around the firewall, netsync via mtn: from there. > > Some really secure labs forbid both 1 and 2 for security reasons (holes > in firewalls are dangerous, U

Re: [Monotone-devel] 0.48 rants

Derek Scherger spake unto us the following wisdom: > On Sat, Jul 17, 2010 at 3:03 PM, Aaron W. Hsu wrote: > > With all the negative responses regarding the new changelog editor, I > > just thought I would weigh in with something a little more positive. I > > actually do like the changes, on a whol

Re: [Monotone-devel] Quick poll: monotone-users list?

Thomas Keller spake unto us the following wisdom: > The discussion came up yesterday that some people are annoyed of the > amount of tickt / savannah spam on the development list. I proposed to > setup a dedicated "monotone-users" list which would not get these > messages and which could serve as e

Re: [Monotone-devel] 0.48 rants

Markus Wanner spake unto us the following wisdom: > I've recently upgraded to mtn 0.48 and certainly appreciate some of the > improvements. However, I find it utterly annoying to have to scroll down > to enter the commit message in the editor. None of any other VCS I know > does that. I'd like to r

[Monotone-devel] [bug #30215] mtn ci aborts with 'mtn: misuse: Commit cancelled.' and fails to save log message when commit header is modified

URL: Summary: mtn ci aborts with 'mtn: misuse: Commit cancelled.' and fails to save log message when commit header is modified Project: monotone Submitted by: eblanton Submitted on: Tue 22 Jun 201

Re: [Monotone-devel] Release time

Derek Scherger spake unto us the following wisdom: > > 1) if a release only consists of bug fixes or has small, not BC-breaking > > improvements (esp. in respect to automate), raise the patch release > > > > 2) if a release has bigger improvements or breaks BC, raise the minor > > version > > > > 3

Re: [Monotone-devel] Server broken

Jack Lloyd spake unto us the following wisdom: > On Sat, Oct 10, 2009 at 11:51:19AM -0400, John Bailey wrote: > > Virtual machines, especially those provided by OpenVZ and Virtuozzo, > > are not the greatest things in the world--the seller can overcommit > > the physical hosts or the hosts can be u

Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

Derek Scherger spake unto us the following wisdom: > One discussion that we've had before centers around protocol version numbers > verses specific features. Iirc SMTP's EHLO command may respond with a list > of keywords indicating the various optional features that a particular > implementation su

Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

Thomas Keller spake unto us the following wisdom: > However, I strongly oppose to revert the current work from Timothy in > nvm, just because this would put this particular, very useful change > back on a work bench where it is easy to get forgotten about. There are > no other big changes sitting i

Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

Timothy Brownawell spake unto us the following wisdom: > Some reasons for this one getting less discussion than otherwise are > that it's fixing a longstanding bug with moderately severe consequences > (which was starting to really annoy the pidgin people), that there > wasn't anything else to batc

Re: [Monotone-devel] Text under revision control

hend...@topoi.pooq.com spake unto us the following wisdom: > Now the VCS could use a different difference algorithm when processing > them. Or it could unpack them into something easier to process (like a > sequence of words instead of lines). Or the word-processor could use a > better file-fo

Re: [Monotone-devel] stripped has landed

Zack Weinberg spake unto us the following wisdom: > I've just landed .stripped. .stripped does not build on Ubuntu Hardy (their "Long Term Support" version) due to unavailability of pcre 7.6 or newer in the official repositories. (Hardy currently ships with 7.4.) Attached is a patch to configure

Re: [Monotone-devel] Dealing with lost key

dlakelan spake unto us the following wisdom: > Ethan Blanton wrote: >> Note that it is actually sufficient to sign only the newest known good >> revisions, and the transitive closure of the revision graph will >> capture all good revisions. > > Is this "sufficient

Re: [Monotone-devel] Dealing with lost key

Brian May spake unto us the following wisdom: > I would simplify this to a even more common problem: > > Person A, after numerous contributions to the project discovers is > laptop computer has been stolen, and as such cannot be sure the security > of his private key is still intact. > > He wants

Re: [Monotone-devel] interface versions, again

Stephen Leake spake unto us the following wisdom: > While we are on this topic, can I request that the monotone version be > bumped to 0.43 immediately after the release, rather than immediately > before the next release? That makes it easier for development versions > of Emacs DVC (and other simil

Re: [Monotone-devel] date certs on net.venge.monotone

Bruce Stephens spake unto us the following wisdom: > Markus Wanner <[EMAIL PROTECTED]> writes: > > What surprised me about the pidgin repository is, that there are some > > date certs with six digits (!) for milliseconds in the date, i.e.: > > "2006-11-01T21:39:36.807940" > > IIRC Tailor did that

Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL

Daniel Carrera spake unto us the following wisdom: >> Robert was asking for clarification, which is a reasonable thing to >> do. There is no need to be snide or rude about it. If you have a >> legitimate use case, and can articulate it, then software can be built >> to accomodate it. If you cann

Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL

I'm not sure this is useful, but here goes. Robert White spake unto us the following wisdom: > As for bob+foocorp; people who expect to be able to use the email > addresses aren't necessarily going to be wanting to see/create/use > +foocorp, nor remove same, particularly since now you are leaking

Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL

Robert White spake unto us the following wisdom: > Daniel Carrera wrote: > > Robert White wrote: > >> If you don't believe in these use cases, consider contractors who may > >> need to keep work separate for different employers but will want to > >> use their one business email address for all thei

Re: [Monotone-devel] Monotone Security

Daniel Carrera spake unto us the following wisdom: >> All security has to go in the *recipient*, because the >> sender could be completely malicious. > > Of course. Every check I have suggested has been server-side > (recipient). The client (sender) is completely malicious. The server isn't (ne

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] db kill_rev_locally

Daniel Carrera spake unto us the following wisdom: >> Then, to connect to the server, run something like the following on >> your workstation: >> >> ssh -L4691:localhost:4691 >> >> This somewhat confusing command line says "Forward port 4691 (the >> leading 4691:) on the local host (-L) to por

Re: [Monotone-devel] db kill_rev_locally

Daniel Carrera spake unto us the following wisdom: >> If you have to serve through ssh, you'd be much better off starting a >> netsync server somewhere on a localhost port, and tunneling that port >> through ssh. That will take care of both concurrency and your security >> concerns in a much cleane

Re: [Monotone-devel] db kill_rev_locally

Daniel Carrera spake unto us the following wisdom: >> In general, yes, audit trails are great -- but make sure your >> prevention and detection match the threat model you're supposing. > > See my last email. There are standard ways to avoid modification of the > database file through anything but

Re: [Monotone-devel] db kill_rev_locally

Daniel Carrera spake unto us the following wisdom: > Against this particular attack, Monotone only has recovery. Monotone has > a great recovery system, but something in the way of prevention or > detection would be a worthy improvement. For example: > > 1) Prevention: Remove or somehow restric

Re: [Monotone-devel] while i'm on the subject, other things that ought to be done to key handling...

Zack Weinberg spake unto us the following wisdom: > The on-disk keystore format is currently a single file per keypair > containing a packet representation of both the public and private > keys. It should be changed to two files per keypair, one with the > public and one with the private key, each

Re: [Monotone-devel] Future of monotone

Daniel Carosone spake unto us the following wisdom: > [slowly working through a big mail backlog] > > On Mon, Jan 28, 2008 at 12:17:54PM -0500, Ethan Blanton wrote: > > 5) Workspace merge. This was started, but never finished. > >3-way-merge tools are all well and go

Re: [Monotone-devel] Future of monotone

Thomas Keller spake unto us the following wisdom: > There are still quite a lot dedicated people who care about this > software (put yourself on the list if you read this with a tear in your > eye) and I'm sure all these people don't want to let this software die > silently. On the other hand it

Re: [Monotone-devel] speed of "mtn ls branches"

William Uther spake unto us the following wisdom: > Is the 0.2 seconds a huge issue for you? 0.2 seconds may not be a big deal, but ... for a Pidgin monotone database (im.pidgin.* from pidgin.im), the difference is more like 2.75 seconds, with a hot cache. 0.36 lists the database in 120ms, wherea

Re: [Monotone-devel] Key identities...

Nathaniel Smith spake unto us the following wisdom: > It already does error out if you try to put two keys with the same > name into the same db. I'm not quite sure how the developer in > question managed to achieve this -- maybe Ethan will explain in more > detail. It sounds like he once upon a

Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']

Zack Weinberg spake unto us the following wisdom: > On 10/8/07, Ethan Blanton <[EMAIL PROTECTED]> wrote: > > > It's a good idea but you need to be careful how you implement it. > > > Hardwiring VT220 color control codes would be bad. So would making us > > &

Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']

Zack Weinberg spake unto us the following wisdom: > On 10/8/07, Lapo Luchini <[EMAIL PROTECTED]> wrote: > > We could, in fact, add a --color option to "mtn diff" itself... > [...] > > Also "mtn log" and "mtn status" would have a big benefit from colors, in > > fact. It could be nice to use them...

Re: [Monotone-devel] Re: [PATCH] parent selector 'p:xxx'

Lapo Luchini spake unto us the following wisdom: > Ethan Blanton wrote: > > Even when it is correct, for > > Pidgin it often has 3-5 parallel lines at two columns apiece, and > > often it mistakenly draws O(a lot) of parallel lines. > > BTW: As far as correctness

Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'

Derek Scherger spake unto us the following wisdom: > On a slightly related note I think I've seen quite a few things saying > "--no-graph" lately and I wonder if that should really be the default? I believe that it should; if it is more than just a few columns wide, it tends to make diffs and comm

Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'

Ralf S. Engelschall spake unto us the following wisdom: > Yes, such a command is such good that I recently even tried to implement > it in Lua with the help of mtn_automate() -- I just failed because > of a bug in mtn_automate() which I reported recently, too. The name > for the command would be "m

Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'

Nathaniel Smith spake unto us the following wisdom: > > Of course, there is really no reason this can't be handled as a shell > > alias or simple script, either... > > Except that making users write their own code to fix our bugs is > stupid :-). Of course. :-) > 'summarize' still seems too lon

Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'

Nathaniel Smith spake unto us the following wisdom: > "Show me stuff about revision " seems like a pretty fundamental > command -- "stuff" presumably including some metadata summary like log > gives you, and also a diff or so. Does anyone have a good idea for > what this command would be called?

Re: [Monotone-devel] Re: cannot drop non-empty directory during branch update

William Uther spake unto us the following wisdom: > On 19/09/2007, at 12:51 PM, Ethan Blanton wrote: > >William Uther spake unto us the following wisdom: > >>Hrm - if the files are auto-generated, then you should just delete > >>them. You can re-generate them when you u

Re: [Monotone-devel] Re: cannot drop non-empty directory during branch update

Ethan Blanton spake unto us the following wisdom: > There is another possibility -- maybe they are simply expensive to > generate. Several times in renaming directories in the Pidgin source > tree, I've had to blow away quantities of object files which I would > rather have kept,

Re: [Monotone-devel] Re: cannot drop non-empty directory during branch update

William Uther spake unto us the following wisdom: > Hrm - if the files are auto-generated, then you should just delete > them. You can re-generate them when you update back to this revision > again. But you say you don't want to do that, so I assume that they > have original data. In which

Re: [Monotone-devel] mtn copy anyone?

Brian May spake unto us the following wisdom: > Nathaniel> actually affect the history model -- then there are > Nathaniel> questions like how it works through merging. This is > Nathaniel> unclear too; there are a few alternative, contradictory > Nathaniel> "natural" semantics for

Re: [Monotone-devel] Lack of conflicts checking

Nathaniel Smith spake unto us the following wisdom: > On Tue, Aug 07, 2007 at 10:19:49PM -0400, Ethan Blanton wrote: > > So, not to throw a wrench into the mix, here ... but die-die-die has > > come up quite a few times in Pidgin development, and we've already had > > to

Re: [Monotone-devel] Lack of conflicts checking

Nathaniel Smith spake unto us the following wisdom: > Anyway: Technically we *could* start detecting that conflict you > describe, end-user-wise I could be convinced that we *should* start > detecting that conflict you describe, and also there is some question > to be resolved over how we would rep

Re: [Monotone-devel] branch abbreviations

Derek Scherger spake unto us the following wisdom: > Fri Jun 15 14:46 < elb> boy, I would love some branch aliases > Fri Jun 15 14:47 < elb> so I could use, e.g., ipp to get > im.pidgin.pidgin, and ipp.whatever ot get im.pidgin.pidgin.whatever [snip] > how about something like this: > > [EMAIL P

Re: [Monotone-devel] slow update/status on NFS

Nathaniel Smith spake unto us the following wisdom: > To start with, there's absolutely no need to check that a path is a > file before opening it for reading -- if it's not a file, then the > read will fail just fine on its own. I threw that assertion in > because at the time I figured if we were

Re: [Monotone-devel] Re: Announce: DisTract - Distributed Bug Tracker based on Monotone

Bruce Stephens spake unto us the following wisdom: > Paul Crowley <[EMAIL PROTECTED]> writes: > > The big win is really having version control at all. Treating each > > bug as a collaboratively edited document is just the Right Thing; it > > means that history and merging are correctly handled, re

[Monotone-devel] Roster-related crash (somewhat of an abuse?)

Hi all, Monotone does not seem to deal with extant but unreferenced rosters which are regenerated by a new commit gracefully. Viz: mtn -d test.mtn db init mkdir test cd test echo "Test to crash monotone" > test.txt mtn -d ../test.mtn setup -b org.example.monotone.test mtn add test.txt mtn ci -m

Re: [Monotone-devel] Question on layering

Paul Crowley spake unto us the following wisdom: > What proportion of the network traffic is MAC packets? That will go > down when we switch to SSL. There are no MAC "packets"; there is a MAC appended to every higher-layer netsync object. For small objects, that would be nontrivial overhead. H

Re: [Monotone-devel] Question on layering

Nathaniel Smith spake unto us the following wisdom: > > vii) convenience commands. mtn clone == mtn pull --partial && mtn > > co (and puts the partial repository in the _MTN directory of the > > working copy). mtn pcmp == mtn pull && mtn commit && mtn merge && > > mtn push. mtn pu == mtn

[Monotone-devel] Re: re-licensing the monotone manual

Nathaniel Smith spake unto us the following wisdom: > PLEASE REPLY TO THIS EMAIL, CC'ING monotone-devel@nongnu.org, AND > SAY THAT YOU ARE FINE WITH YOUR CONTRIBUTIONS TO monotone.texi BEING > RELEASED UNDER THE GPL (v2 or later). I have no problem with my contributions to the monotone manua

Re: [Monotone-devel] iconv diffs [Was: Why is utf8...]

Patrick Georgi spake unto us the following wisdom: > but skipping a character should be possible: > - build another iconv state that translates input encoding into input > encoding (unless that enables a fast-path, which I'm not sure of - > alternative might be some encoding that is the ultimate

Re: [Monotone-devel] project_t , and preparing for projects / policy branches

Nathaniel J. Smith spake unto us the following wisdom: > > Except that tagging is explicit, whereas a 'mtn ci' in the wrong > > workspace or with the wrong branch name set from some previous > > command is really easy to do. This is one of the bigger problems > > I have with svn -- that there is n

Re: [Monotone-devel] project_t , and preparing for projects / policy branches

Nathaniel J. Smith spake unto us the following wisdom: > > Also, the mentioned get_tags() returns a set of new "tag" objects. The > > code that used it wanted to know the key used for signing the tag, but I > > don't think it's at all certain that tags will remain implemented as > > certs (putting

Re: [Monotone-devel] Repeatable 'monotone serve' crash

Thomas Moschny spake unto us the following wisdom: > On Friday 05 January 2007 21:40, Timothy Brownawell wrote: > > An empty xdelta is not the same as an xdelta that does nothing. The > > invariant is based on a wrong assumption, and should be removed. > > Removed it. This fixed my problems handi

[Monotone-devel] Repeatable 'monotone serve' crash

When serving the monotone database at: http://www.cs.purdue.edu/homes/eblanton/private/ical.mtn Using the config file: http://www.cs.purdue.edu/homes/eblanton/private/ical.monotonerc ... the monotone server crashes on a pull of 'net.elitists.ical' into an empty database. I can repeat this reli

Re: [Monotone-devel] question regarding stdio and streams

Nathaniel J. Smith spake unto us the following wisdom: > On Wed, Dec 20, 2006 at 01:13:01PM -0500, Ethan Blanton wrote: > > Thomas Keller spake unto us the following wisdom: > > > Apparently informational messages (printed with the P() macro) and > > > ticker output g

Re: [Monotone-devel] question regarding stdio and streams

Thomas Keller spake unto us the following wisdom: > Apparently informational messages (printed with the P() macro) and > ticker output goes to clog instead of cout. If I want to move those > output to the stdio output, which currently only processes cout, what > would be the supposed way? It would

Re: [Monotone-devel] Summit brainstorming

Christof Petig spake unto us the following wisdom: > - a cvs server process against a monotone database (if there's _any_ > benefit) This is an interesting suggestion; I assume you mean a monotone "server" process which serves (perhaps read-only) to a generic cvs client? We have discussed providi

Re: RFC: mtn split (Was: [Monotone-devel] Best practice using monotone)

Daniel Carosone spake unto us the following wisdom: > The 'split' command seems like an interesting idea; if I understand > correctly, it would create lots of parallel BB1, BB2, BB3... revisions > as children of A, in the above example. The problem I forsee with > this is that it will create a lot

Re: [Monotone-devel] thought on hierarchical branches

Nathaniel Smith spake unto us the following wisdom: > In particular, I was sort of leaning towards saying that actual > branches should be leaves -- if we follow the scheme we use now, we'd > have branches > monotone > monotone/foo > monotone/bar > etc., and that seems confusing when these ar

Re: PGP key signing (Was: Re: [Monotone-devel] Re: BZ2 & signatures)

Jack Lloyd spake unto us the following wisdom: > On Tue, Aug 01, 2006 at 04:25:33PM -0400, Ethan Blanton wrote: > > So, not to get into a big long PGP discussion here, but this is really > > not that useful. I'm well-signed into the strongly connected subset, > > myself,

PGP key signing (Was: Re: [Monotone-devel] Re: BZ2 & signatures)

Lapo Luchini spake unto us the following wisdom: > Nathaniel Smith wrote: > > (Also, I'm the one that rolls releases these days, and I don't have a > > verifiable gpg key anyway...) > > If you're interested in improving your key reachability I may suggest > exchanging signatures with Matt Zimmerman

Re: [Monotone-devel] Re: RFC: Fake IDs

Jack Lloyd spake unto us the following wisdom: > On Tue, Jul 18, 2006 at 06:39:49PM -0700, Zack Weinberg wrote: > > Perhaps I only say this because I am not a cryptographer at all, but > > it seems to me that the collision probability results might depend on > > the assumption that both sides of th

Re: [Monotone-devel] [RFC] M.T. phone home

Nuno Lucas spake unto us the following wisdom: > >Hrm, there is a minor problem with this approach, which is that > >needing an "optimize" command at all is a bug; a design goal is that > >we would be fast without requiring users bother with such things. > >(Compare how annoying it is to have to "d

Re: [Monotone-devel] slick pictures

Nathaniel Smith spake unto us the following wisdom: > On Thu, May 18, 2006 at 12:27:16AM -0700, Nathaniel Smith wrote: > > I'm not sure exactly what "hg import" does; patch has a lot of > > complicated heuristics in it that it may or may not duplicate. > > Ah-hah: > > def patch(strip, patchname,

Re: [Monotone-devel] Re: results of mercurial user survey

Markus Schiltknecht spake unto us the following wisdom: > thank you for your answer. > > On Fri, 2006-04-28 at 15:49 +0100, Bruce Stephens wrote: > > Except if the sending end has bogus data (as happened with the > > venge.net server). > > Even in that case, netsync (tcp, really) guarantees to co

Re: [Monotone-devel] Google Summer of Code 2006

Richard Levitte - VMS Whacker spake unto us the following wisdom: > In message <[EMAIL PROTECTED]> on Fri, 21 Apr 2006 11:29:00 -0400, Ethan > Blanton <[EMAIL PROTECTED]> said: > eblanton> Richard Levitte - VMS Whacker spake unto us the following wisdom: > eblanton>

Re: [Monotone-devel] Google Summer of Code 2006

Richard Levitte - VMS Whacker spake unto us the following wisdom: > In message <[EMAIL PROTECTED]> on Fri, 21 Apr 2006 09:54:17 -0500, Chad > Walstrom <[EMAIL PROTECTED]> said: > > There's the Postfix way of launching new services, a master server. > > usher could make requests of the master serve

Re: [Monotone-devel] Usher difficulties

Richard Levitte - VMS Whacker spake unto us the following wisdom: > In message <[EMAIL PROTECTED]> on Mon, 10 Apr 2006 09:48:49 -0400, Ethan > Blanton <[EMAIL PROTECTED]> said: > eblanton> First, usher has not been updated to exec 'mtn' by default > eblanton&g

[Monotone-devel] Usher difficulties

First, usher has not been updated to exec 'mtn' by default rather than 'monotone'; this is not a big deal to work around (usher -m mtn), but the default should probably be changed. A trivial patch is attached. Second, with both the usher from 0.26-pre3 and the usher from 0.26 as released, I am ha

Re: [Monotone-devel] Can anyone check for the old ipv6 bug?

Nathaniel Smith spake unto us the following wisdom: > On Thu, Apr 06, 2006 at 06:08:01PM -0400, Ethan Blanton wrote: > > I still get this error. I'll try to look into it soon. > > Does this mean, you see this error with 0.25 and will try 0.26 soon, > or that you tried 0.26

Re: [Monotone-devel] Can anyone check for the old ipv6 bug?

Nathaniel Smith spake unto us the following wisdom: > 0.25 etc. had a bug where on various old systems that didn't actually > have IPv6 support, 'monotone serve' wouldn't work unless you used > something like 'monotone serve --bind='. Can anyone > who used to have this problem confirm that it is f

[Monotone-devel] Rosterification problem

Hi all, I have a database which I cannot rosterify, either with what I believe is released 0.26pre2 (9ca37b918cb5309d8d3b0be000dc8a1151df262f) or head (currently 4d531a78b9ef029b50a0507c932aaacdab8a432e). I get the following error with both revisions: monotone: fatal: std::logic_error: error in

Re: [Monotone-devel] Re: rename boundary failure in 0.25

Nathaniel Smith spake unto us the following wisdom: > On Thu, Mar 09, 2006 at 03:04:54PM -0500, Shawn Samuel wrote: > > Also, as far as I can tell, there is no way to set the default key in > > monotonerc. Am I just missing something, or is there a reason for > > this? > > Just the general reason

Re: [Monotone-devel] Re: the line-ending discussion

Graydon Hoare spake unto us the following wisdom: > Operations 1 and 2 are done by splitting or joining. The split and join > operations are governed by the following rules: > >- At first, monotone's default behavior will be to use the "native" > line-ending forms (only LF on unix, only

Re: [Monotone-devel] Re: Bug in CRLF conversions

Richard Levitte - VMS Whacker spake unto us the following wisdom: > In message <[EMAIL PROTECTED]> on Wed, 1 Feb 2006 21:19:37 -0500, Ethan > Blanton <[EMAIL PROTECTED]> said: > eblanton> Given this set of rules, I claim that *text conversions* are > eblanton>

Re: [Monotone-devel] line endings

Howard Spindel spake unto us the following wisdom: > It seems to me that to be completely general monotone needs a > per-file certificate specifying the permissible > transformations. Examples of the settings available in that certificate: > > 1. Never transform anything > 2. Database file is

Re: [Monotone-devel] Re: Bug in CRLF conversions

Richard Levitte - VMS Whacker spake unto us the following wisdom: > In message <[EMAIL PROTECTED]> on Wed, 1 Feb 2006 07:24:22 -0500, Ethan > Blanton <[EMAIL PROTECTED]> said: > eblanton> Richard Levitte - VMS Whacker spake unto us the following wisdom: > eblanton>

Re: [Monotone-devel] Re: Bug in CRLF conversions

Richard Levitte - VMS Whacker spake unto us the following wisdom: > mlh> On Tue, Jan 31, 2006 at 07:50:51AM -0500, Yury Polyanskiy wrote: > mlh> > Again: solution is trivial. "Transform what I ask you to > mlh> > (LF->CRLF and back) and don't mess with anything special (like > mlh> > CR->CRLF etc).

Re: [Monotone-devel] Re: Bug in CRLF conversions

Thomas Moschny spake unto us the following wisdom: > Quoting Matthew Hannigan: > > On Tue, Jan 31, 2006 at 07:50:51AM -0500, Yury Polyanskiy wrote: > > > Again: solution is trivial. "Transform what I ask you to (LF->CRLF and > > > back) and don't mess with anything special (like CR->CRLF etc)." > >

Re: [Monotone-devel] Re: Bug in CRLF conversions

Richard Levitte - VMS Whacker spake unto us the following wisdom: > In message <[EMAIL PROTECTED]> on Sun, 29 Jan 2006 16:26:13 -0500, Yury > Polyanskiy <[EMAIL PROTECTED]> said: > ypolyans> Some motivation why maybe it still should be done. Why we > ypolyans> want line endings translation at all?

Re: [Monotone-devel] Re: Syncing databases without using a network?

Bruce Stephens spake unto us the following wisdom: > Ethan Blanton <[EMAIL PROTECTED]> writes: > It might be helpful if someone took a small repository on one > architecture, pulled it to another one, and made the two accessible in > some way. If I remember correctly, it was

Re: [Monotone-devel] Syncing databases without using a network?

Nathaniel Smith spake unto us the following wisdom: > On Wed, Jan 25, 2006 at 03:34:32PM -0600, Chad Walstrom wrote: > > Be careful with USB keys. In my experience, you'll run in to integer > > size problems with the database format. For example, I cannot access > > a monotone database (SQLite) o

Re: [Monotone-devel] Syncing databases without using a network?

Richard Levitte - VMS Whacker spake unto us the following wisdom: > In message <[EMAIL PROTECTED]> on Wed, 25 Jan 2006 18:03:19 +0100, Christof > Petig <[EMAIL PROTECTED]> said: > > christof> --->8-- > christof> #!/bin/sh > christof> monotone -d $1 serve --bind localho

Re: [Monotone-devel] some (negative) feedback -- useful reading

Nathaniel Smith spake unto us the following wisdom: > I don't know what "disapprove, true merges are hard" means. I don't > know what "phil does not have send a key" means. (Who is Phil? :-)) I don't know about the first two, but I can guess about "true merges are hard", because it's an issue I

Re: [Monotone-devel] Commit a child of 2 parents

Daniel Carosone spake unto us the following wisdom: > On Sun, Jan 15, 2006 at 10:31:13PM -0500, Yury Polyanskiy wrote: > > This won't handle all situations: suppose a merge revision that adds a > > file. I can't direct monotone to add a new file via merge hook. > > Yeah, but on the other hand I do

Re: [Monotone-devel] Is l10n a little off?

Nathaniel Smith spake unto us the following wisdom: > On Sun, Jan 15, 2006 at 02:16:40PM +0100, Richard Levitte - VMS Whacker wrote: > > Heh, on the other hand, the same thing usually happens to the > > translators as well, and I guess the worst is when you end up with a > > bunch of fuzzy entries.

Re: [Monotone-devel] branch naming conventions

Nathaniel Smith spake unto us the following wisdom: > This is also somewhat problematic (though this hasn't come up as > much yet, though it probably will as monotone usage grows), > because it means that if the, say, "[EMAIL PROTECTED]" key goes bad, > like it gets compromised

Re: [Monotone-devel] Compiling from source

Zbynek Winkler spake unto us the following wisdom: > Ok, the problem seems to be boost-1.32. It is linked with libstdc++.so.5 > but gcc-4.0 uses libstdc++.so.6 so the resulting executable links to > both and that seems to be the problem :( > > So, I installed boost-dev (1.33) from debian unstabl

Re: [Monotone-devel] Re: Transport encryption

Bruce Stephens spake unto us the following wisdom: > Nathaniel Smith <[EMAIL PROTECTED]> writes: > > We can already do replication across multiple hosts, that are > > heterogenous in any way I can think of, and the replication is > > secure against tampering, man-in-the-middle, and so on -- it's ju

Re: [Monotone-devel] I need a better diff

Hendrik Boom spake unto us the following wisdom: > I'm in the position of needing a better diff -- I have multiple > versions of text files. I need to compare them, and of course diff is > led hopelessly astray by the fact that small changes in a paragraph > have caused line breaks to move to diffe

Re: [Monotone-devel] Re: ~/.monotone/keys , privkey packets

Timothy Brownawell spake unto us the following wisdom: > > If you look in commands.cc, you will see that the privkey command > > writes both the private and public key to the file. You can even just > > try the 'monotone privkey' command and look at the output (it's > > ASCII). > > Yes, but they'

Re: [Monotone-devel] resend : i18n

Nathaniel Smith spake unto us the following wisdom: > Another question is what to do with log messages, the L() macro. Logs > are only displayed when run with --debug or after a crash; they are > more intended for developers than for users, so this might argue for > leaving them in English (since

Re: [Monotone-devel] quick poll

(Pardon if this was already concluded in-channel or elsewhere, I have been on vacation.) Nathaniel Smith spake unto us the following wisdom: > Should it be possible to commit with an empty changelog, if someone > really wants to? Like, if they actually pass '-m ""' on the command > line or whatev

Re: [Monotone-devel] Re: [ANNOUNCE] monotone 0.21 released

Nathaniel Smith spake unto us the following wisdom: > > That behavior forces you to specify all --excluded branches > > on the command line every time you sync, and that's pretty > > uncomfortable. (Default patterns don't help me when I have > > to sync to different servers with different configura

Re: [Monotone-devel] UI to push/pull/sync

Nathaniel Smith spake unto us the following wisdom: > Currently, on mainline, push/pull/sync have been changed to take a > regular expression instead of a collection -- collections don't exist > anymore. Functionally, this is great; UI-wise, I'm wondering how cool > it really is to be typing "net\

[Monotone-devel] Merge behavior w.r.t. file operations

Hi all, This is a summary of my viewpoint of how file operations (add, delete, rename) should work during branch merges, at least partially in reaction to the long thread "3-way merge considered harmful". I am posting this summary at the behest of Nathaniel, so hopefully it includes what h