Re: [ctwm] Re: mtn-isms
In message [EMAIL PROTECTED] on Mon, 3 Dec 2007 23:18:36 -0600, Matthew D. Fuller [EMAIL PROTECTED] said: fullermd Richard, fullermd fullermd [...] How do other mtn-using projects do this? [...] fullermd fullermd Any thoughts on this? Cert-less revs seem like they have fullermd bad side effects even aside from the seeming semantic fullermd imprecision, but all these obvious alternatives are pretty fullermd messy... Didn't I already comment on this? Actually, I don't have much experience from other mtn-using projects except for monotone itself. Quite honestly, I don't really see a problem, except for the fact that things look a bit weird in mtn-viz. (oh, and you mean branch-less revs, right? ;-)) There's a very simple rule with monotone: no part of the history goes away (branch certs aren't considered part of the history, they are just certs... markers if you will). Of course, as long as your revisions are only present in your own database, you can do whatever you want as long as you know what you're doing, but as soon as things get distributed, there's really no guaranteed way to lose any revision. Most projects that I know of simply adapt, and it's not even difficult. Cheers, Richard
[ctwm] Re: mtn-isms
On Fri, Nov 23, 2007 at 02:40:06PM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: One way, a bit complicated but still workable: I would simply have kept hacking and committing into free.lp.se:X.ctwm in a separate database (ctwm.fullermd) [...] Mmm. The downside of that is making a repo for every new [concurrent] branch. That's awful heavy-weight. Even simple, though, is to just keep one database, but then hack away as needed, maybe in a separate workspace, commit whenever you feel like, and when you're done, pull from guardian, merge and push. But the downside of THAT is that I can only do one thing at a time, have to run it to completion before touching anything else, and a poorly-timed push will end up putting that incomplete stuff out in the world as another head on the branch to mess with other people. I don't much like that either :| How do other mtn-using projects do this? Presumably, cert-less revisions are a sufficiently Bad Thing(tm) that it's not an intended result (otherwise, -viz would treat them a little better). Certainly working one thing to completion at a time defeats the whole point of branching. I don't believe the standard workflow involves creating a new repo for every transient branch. And I have a really hard time believing every mtn-using project just grows an ever-increasing number of branches. That would be nuts; I've got plenty of rather small projects where that list would run to 50 or 80 branches, with all but 1 or _maybe_ 2 of them being defunct and pointless. And some of them would be _completely_ worthless, because they were branches that were made to try something that turned out to be a bad idea, and so were discarded without ever being merged. And that leaves completely aside the nastiness of globally-unique naming of the branches, avoiding which is one of the big plusses of the D in DVCS. If it's gonna be globally visible, or even eternally locally visible, I could never make a X.ctwm.compiler_errors; it would have to be X.ctwm.fullermd.compiler_errors.200710 or something even more painfully unwieldy and potentially misleading like that. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Re: mtn-isms
In message [EMAIL PROTECTED] on Fri, 23 Nov 2007 05:22:30 -0600, Matthew D. Fuller [EMAIL PROTECTED] said: fullermd Well, OK (and in my database, they're not on X.ctwm, fullermd they're on free.lp.se:X.ctwm.compiler_errors, so even a viz fullermd on X.ctwm there wouldn't show them?). But if prop doesn't fullermd do so (why not?), how WOULD I have brought those changes in fullermd so that they got certs for the X.ctwm branch? I mean, fullermd they're SUPPOSED to be on that branch now, right? Shouldn't fullermd they be noted as such? 1) if the off side branch really is free.lp.se:X.ctwm.compiler_errors, it should be visible to the rest of us, since my server accepts the glob free.lp.se:X.ctwm*. There are already a few other subbranches that prove this. 2) mtn propagate only creates a new revision that is placed in the target branch, it doesn't add any branch certs to already existing revisions. But then, you didn't do a propagate either, you just commited 4da54949171b2cc1c5f467318daf87b683a77d9b into free.lp.se:X.ctwm, didn't you? Or alternatively, you simply added a branch cert to it? If you want all those revisions that are currently branch-less to the rest of us into free.lp.se:X.ctwm, you will simply have to add a branch cert to each of them, like this: mtn cert 6eb1af5f822cafe715c4e46f37ea3bc808e7a5f5 branch free.lp.se:X.ctwm But you know, before doing so, I'd like you to recheck that there's no spelling error in free.lp.se:X.ctwm.compiler_errors that made it fall outside of the pattern accepted by guardian. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis
[ctwm] Re: mtn-isms
In message [EMAIL PROTECTED] on Fri, 23 Nov 2007 06:31:48 -0600, Matthew D. Fuller [EMAIL PROTECTED] said: fullermd On Fri, Nov 23, 2007 at 01:16:20PM +0100 I heard the voice of fullermd Richard Levitte, and lo! it spake thus: fullermd In message [EMAIL PROTECTED] on Fri, 23 Nov 2007 05:22:30 -0600, Matthew D. Fuller [EMAIL PROTECTED] said: fullermd fullermd 1) if the off side branch really is free.lp.se:X.ctwm.compiler_errors, fullermd it should be visible to the rest of us, since my server accepts the fullermd glob free.lp.se:X.ctwm*. There are already a few other fullermd subbranches that prove this. fullermd fullermd Well, that was the point of the workflow; X.ctwm.compiler_errors fullermd only exists in my 'ctwm.fullermd' repo, from which only fullermd X.ctwm gets pushed into my 'ctwm' repo, which is the one fullermd that talks to guardian. Oh, right, I see, so the revisions got pushed but not the branches other than free.lp.se:X.ctwm because that's the pattern you use when pushing? That makes sense. fullermd No, I did prop it: fullermd % history | grep 'mtn prop' fullermd 48 11:41 time mtn prop free.lp.se:X.ctwm.compiler_errors free.lp.se:X.ctwm Ah, and the following explains it: fullermd No merge rev was created because X.ctwm's head hadn't moved fullermd since I branched off into X.compiler_errors. 4da549 was the fullermd head on X.ctwm.compiler_errors at the time I did the prop fullermd (and is still the head of course; I update'd my workspace fullermd away from that branch and don't intend to ever look at it fullermd again). That's a special case where propagate simply adds a branch cert with the target branch to the head of the originating branch. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis
[ctwm] Re: mtn-isms
On Fri, Nov 23, 2007 at 01:41:35PM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: Ah, and the following explains it: So, the question is, what should be done differently to avoid these broken bits (or at least pitfalls) in the future? Surely there's some answer less annoyingly manual than setting certs on a bunch of revisions one at a time (and hoping not to miss any). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Re: mtn-isms
In message [EMAIL PROTECTED] on Fri, 23 Nov 2007 06:52:03 -0600, Matthew D. Fuller [EMAIL PROTECTED] said: fullermd On Fri, Nov 23, 2007 at 01:41:35PM +0100 I heard the voice of fullermd Richard Levitte, and lo! it spake thus: fullermd fullermd Ah, and the following explains it: fullermd fullermd So, the question is, what should be done differently to fullermd avoid these broken bits (or at least pitfalls) in the fullermd future? Surely there's some answer less annoyingly manual fullermd than setting certs on a bunch of revisions one at a time fullermd (and hoping not to miss any). One way, a bit complicated but still workable: I would simply have kept hacking and committing into free.lp.se:X.ctwm in a separate database (ctwm.fullermd), and when it was time to merge the work with the trunk, I would have pulled from the main database (ctwm), merged, pushed back and then pushed to guardian. Even simple, though, is to just keep one database, but then hack away as needed, maybe in a separate workspace, commit whenever you feel like, and when you're done, pull from guardian, merge and push. There's a description of a workflow model that touches this issue in http://www.venge.net/mtn-wiki/DaggyFixes . After all, monotone offers excellent merging capabilities. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis
