[Monotone-devel] Re: Switching to monotone from CVS
Mark Hagger <[EMAIL PROTECTED]> writes: > I've been looking quite hard at various SCM's with a view to switching > from CVS. CVS is slowly, but surely, becoming less and less fitting for > our needs. > [...] how stable/reliable is monotone? You didn't write what these needs are exactly. I've found subversion to be a nice and stable replacements for CVS, fixing most of its problems while keeping the centralised model. Commandline and GUI clients for Windows exist. That said, if you need distributed development, monotone seems to be one of the better candidates. I've seen it abort, but it usually does in a safe and easy-to-debug way (defensive programming). I don't know of any large projects betting on it, though. Actually, I haven't heard of reference projects for the other free, distributed SCMs (well, except git, but that's really not stable in the other sense of the word). -- Robbe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Workflow with Monotone
In message <[EMAIL PROTECTED]> on 04 Jun 2005 22:08:56 +0200, Willem Rein Oudshoorn <[EMAIL PROTECTED]> said: woudshoo> Now we plan using certificates heavily, for example: woudshoo> woudshoo> Version: 1.2.0.3 woudshoo> Build:machine xxx: passed|failed woudshoo> Build arguments: special compiler flags used woudshoo> Smoketest: ... passed| failed woudshoo> Regressiontest: ... passed | failed woudshoo> Bug fix implemented: bug nr woudshoo> Devepment environment: rev id of development environment used woudshoo> woudshoo> and a few others. Wow, interesting! Especially to have a specific version cert (I've used tags so far for that kind of thing, but considering you can select on specific cername=certvalue tuples these days, that's not really necessary any longer :-)). woudshoo> Wishlist woudshoo> woudshoo> woudshoo> [A] commit a revision without making changes Hmm, considering what you say further down, you mean "without changes to the files", right? Actually, there's been some discussions on versioned certs lately. I don't really know what that resulted in, though, as I haven't followed the discussion very well... woudshoo> [B] mark a head as a non-head for a branch I'll go into that below. woudshoo> Use case I - Discard work woudshoo> . woudshoo> woudshoo> I have developed on my own branch project.wim woudshoo> But I have been out of the loop for a while, so I want to woudshoo> start again. woudshoo> projectproject.wim woudshoo> woudshoo>A woudshoo> \___ B (empty commit) woudshoo> | did work woudshoo> C woudshoo> . woudshoo> . woudshoo> . woudshoo> X woudshoo> \__ Y woudshoo> woudshoo> woudshoo> Y will be in the same branch, but I do not want C to show woudshoo> up. So I would like to mark "C" as a non-head on the branch woudshoo> project.wim An option is to have project.wim.1, project.wim.2 and so on, or something similar. With some discipline, you can propagate between those sub-branches and may be able to combine things nicely. woudshoo> Use case II - Discard work woudshoo> .. woudshoo> woudshoo> A made a change I which is a mistake woudshoo> woudshoo>A woudshoo>| woudshoo>B woudshoo> woudshoo> B is a mistake, so I want to do: woudshoo> woudshoo> A woudshoo> | \ woudshoo> *B* C (empty commit) woudshoo> woudshoo> and continue to work on C. Just mark woudshoo> B as a non-head and I am happy. woudshoo> If I later decide to continue on B, I just woudshoo> have to explicitly checkout revision B woudshoo> and commit again to create woudshoo> woudshoo> A woudshoo> | \ woudshoo> *B* C woudshoo> | woudshoo> X (empty commit) An option is to use disapprove on B. This creates a new revision (direkt child of B) containing the "anti-patch" of B, and you can continue from there: A | B | Bd | C And if you decide that B is worth picking up again, you can update to it and commit changes starting from it: A | B | \ Bd X | C woudshoo> Use case II - Retroactive branching woudshoo> ... woudshoo> I started making changes and commited them woudshoo> in branch project.wim, but I suddenly decide that woudshoo> they should NOT be in project.wim but in woudshoo> project.wim.experiment woudshoo> woudshoo> So I have woudshoo> woudshoo> A [project.wim] woudshoo> | woudshoo> B [project.wim] woudshoo> woudshoo> woudshoo> And I want B to be in project.wim.experiment. What I woudshoo> do is: woudshoo> (1) add branch certifacet project.wim.experiment to B woudshoo> (2) mark B as a non head for project.wim woudshoo> woudshoo> woudshoo> woudshoo> A [project.wim] woudshoo> | woudshoo> B [*project.wim*] woudshoo> [project.wim.experiment] There's no need to make B a non-head of project.wim. Actually, that would mean that project.wim ends up having no heads, or that A is considered it's head. And really, none of that is needed, just check out or update to the experimental branch, and whatever you commit thereafter will go to that branch, with no regard to what happens in project.wim. woudshoo> Use case III - adding other metadata woudshoo> woudshoo> If we want to make a new build with a different version woudshoo> number, it would be nice to just do an empty commit woudshoo> and attach the new compiler flags and version number woudshoo> to the new revision. Again, there's talk of versioned certs, and that would solve your problem. With the current monotone, you can rely on the multi- value properties of certificates (you can have several certs with the same name and different
[Monotone-devel] "prune-branch" cert implementation issues.
I'm attempting to give people a clean way to mark a revision as "no-longer-a-head-for-branch-X". There are two use cases for a feature like this one: 1) To ignore old branches which have subsequently been merged into the mainline. 2) To mark revisions as unsuitable for merging. However, it is unclear whether these use cases should be combined or should be handled separately. In discussions on IRC, we decided to try to implement at least the first case with a new certificate type, tentatively named a "prune-branch" certificate by dscherger. The functionality is currently implemented by modifying the get_branch_heads() function in cert.cc. Algorithmically speaking the changes is from the present: Find all revisions with branch certs with value X. Remove revisions which are ancestors. to the new: Find all revisions with branch certs with value X. Remove revisions which are ancestors. Find all prune-branch certs with value X. For each revision, discard if it has an attached prune-branch cert. Applying prune-branch certs is easy: you just run monotone cert REVID prune-branch BRANCH. Two questions remain: How should the selection of update targets behave in the presence of prune-branch certs? How should this certificate affect commands which rely on the old behavior of get_branch_heads()? Comments, criticisms, and suggestions would be very welcome. Thanks, Michael ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "prune-branch" cert implementation issues.
On Sun, 2005-06-05 at 17:53 -0400, Michael Stone wrote: > I'm attempting to give people a clean way to mark a revision as > "no-longer-a-head-for-branch-X". There are two use cases for a feature > like this one: > > 1) To ignore old branches which have subsequently been merged into the > mainline. > 2) To mark revisions as unsuitable for merging. (2) seems like an obvious meaning of such a cert. > However, it is unclear whether these use cases should be combined or > should be handled separately. In discussions on IRC, we decided to try > to implement at least the first case with a new certificate type, > tentatively named a "prune-branch" certificate by dscherger. The > functionality is currently implemented by modifying the > get_branch_heads() function in cert.cc. I'd say combined, with (1) being the special case that all heads are pruned. > Algorithmically speaking the changes is from the present: > Find all revisions with branch certs with value X. > Remove revisions which are ancestors. > > to the new: > Find all revisions with branch certs with value X. > Remove revisions which are ancestors. > Find all prune-branch certs with value X. > For each revision, discard if it has an attached prune-branch cert. > > Applying prune-branch certs is easy: you just run > monotone cert REVID prune-branch BRANCH. > > Two questions remain: > How should the selection of update targets behave in the presence of > prune-branch certs? Only automatically choose a rev that isn't pruned from the branch in question. > How should this certificate affect commands which rely on the old > behavior of get_branch_heads()? I'd think the new behavior would be good for all of them. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Workflow with Monotone
On Sun, Jun 05, 2005 at 07:23:46PM +0200, Richard Levitte - VMS Whacker wrote: > In message <[EMAIL PROTECTED]> on 04 Jun 2005 22:08:56 +0200, Willem Rein > Oudshoorn <[EMAIL PROTECTED]> said: > > woudshoo> Use case I - Discard work > woudshoo> . > woudshoo> > woudshoo> I have developed on my own branch project.wim > woudshoo> But I have been out of the loop for a while, so I want to > woudshoo> start again. > woudshoo> projectproject.wim > woudshoo> > woudshoo>A > woudshoo> \___ B (empty commit) > woudshoo> | did work > woudshoo> C > woudshoo> . > woudshoo> . > woudshoo> . > woudshoo> X > woudshoo> \__ Y > woudshoo> > woudshoo> > woudshoo> Y will be in the same branch, but I do not want C to show > woudshoo> up. So I would like to mark "C" as a non-head on the branch > woudshoo> project.wim > > An option is to have project.wim.1, project.wim.2 and so on, or > something similar. With some discipline, you can propagate between > those sub-branches and may be able to combine things nicely. Yes indeed, I know I can do that, but it seems quite cumbersome, and even more tricky to automate. If I can use consistently one branch it is easer to just type in: build project.wim And do not need to remember what particular numbered version I am in right now. > woudshoo> Use case II - Discard work > woudshoo> .. > woudshoo> > woudshoo> A made a change I which is a mistake > woudshoo> > woudshoo>A > woudshoo>| > woudshoo>B > woudshoo> > woudshoo> B is a mistake, so I want to do: > woudshoo> > woudshoo> A > woudshoo> | \ > woudshoo> *B* C (empty commit) > woudshoo> > woudshoo> and continue to work on C. Just mark > woudshoo> B as a non-head and I am happy. > woudshoo> If I later decide to continue on B, I just > woudshoo> have to explicitly checkout revision B > woudshoo> and commit again to create > woudshoo> > woudshoo> A > woudshoo> | \ > woudshoo> *B* C > woudshoo> | > woudshoo> X (empty commit) > > An option is to use disapprove on B. This creates a new revision > (direkt child of B) containing the "anti-patch" of B, and you can > continue from there: > > A > | > B > | > Bd > | > C Yes, but it seems such a hack, from the revision graph it is not very clear what you have done. Also, what happens if you have: A | \ B C | D where B and C are independendly created first, and later it is agreed that we should continue with C and not on D? So we do not want D anymore, but it will forever be ahead, unless you do something nasty like merging D with C: A | \ B C | | D | \ | E where E should equal C. Again, from the revision graph it is not clear at all. While just marking D as a non-head for the branch does not clutter the graph, and you can check by looking at D (and maybe colour it in a graphical display.) that we consider this head to be dead. Also, again, (I discover I am a little bit passionate about this) If I dissapprove a revision, conceptually that is NOT the same as just applying the reversed last changeset. For example how would you dissapprove a merge: A B \ / C > woudshoo> Use case II - Retroactive branching > woudshoo> ... > woudshoo> I started making changes and commited them > woudshoo> in branch project.wim, but I suddenly decide that > woudshoo> they should NOT be in project.wim but in > woudshoo> project.wim.experiment > woudshoo> > woudshoo> So I have > woudshoo> > woudshoo> A [project.wim] > woudshoo> | > woudshoo> B [project.wim] > woudshoo> > woudshoo> > woudshoo> And I want B to be in project.wim.experiment. What I > woudshoo> do is: > woudshoo> (1) add branch certifacet project.wim.experiment to B > woudshoo> (2) mark B as a non head for project.wim > woudshoo> > woudshoo> > woudshoo> > woudshoo> A [project.wim] > woudshoo> | > woudshoo> B [*project.wim*] > woudshoo> [project.wim.experiment] > > There's no need to make B a non-head of project.wim. Actually, that > would mean that project.wim ends up having no heads, or that A is > considered it's head. I do not want A to be considered head. Actually I should have drawn a more complete picture: Desired situation: A [project.wim] | \_ B [project.wim.experiment] C [project.wim] But I made a mistake and have: A [project.wim] / \ [project.wim] C B [project.wim] and I want to fix that. > And really, none of that is needed, just check > out or upda
[Monotone-devel] Re: "prune-branch" cert implementation issues.
Michael Stone <[EMAIL PROTECTED]> writes: > I'm attempting to give people a clean way to mark a revision as > "no-longer-a-head-for-branch-X". There are two use cases for a feature > like this one: > > 1) To ignore old branches which have subsequently been merged into the > mainline. > 2) To mark revisions as unsuitable for merging. That is perfect timing! I suggest something like that and it turns out that you already thought of the same thing. > Find all revisions with branch certs with value X. > Remove revisions which are ancestors. > Find all prune-branch certs with value X. > For each revision, discard if it has an attached prune-branch cert. Seems fine to me. > > Two questions remain: > How should the selection of update targets behave in the presence of > prune-branch certs? Well, what is the problem? Just look at the "pruned" heads of the desired branch and if there is: ONE head, just update to that head MULTIPLE heads, force the user to pick one ZERO heads, warn the user there are no active heads and do nothing. of course you should still be able to supply a specific revision id and that should always be headed. am I missing something some subtle points? > How should this certificate affect commands which rely on the old > behavior of get_branch_heads()? Well, as I see it monotone is just a graph of revisions. This revision graph is partitioned is subgraphs by a selection criteria. Normally this selection criterium is done by branch certificates, but as far as I can tell there is nothing special or magical about branches, theoretical speaking you could just make another subselection. (However it would be nice if this subselection is not totally disconnected.) Some algorithmes that operate on the graph look at heads to facilitate to the user either merging or updating to a latest version. If the user has specifed with a prune-branch that he is not interested in certain heads monotone should respect that choice. So I think the desired behaviour is that all commands should use the new heads algorithm. Wim Oudshoorn. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: "prune-branch" cert implementation issues.
Michael Stone <[EMAIL PROTECTED]> writes: > In discussions on IRC, we decided to try to implement at least the > first case with a new certificate type, tentatively named a > "prune-branch" certificate by dscherger. Oh one minor note, because the certificate says "do not consider this revision a head for branch xxx" I would like the word head in the certificate name. prune-branch suggest something more complicated that it actual is. Unfortunately I don't know anything better than prune-branch, but maybe a variation on: no-head prune-branch-head ignore-branch-head ignore-head But this is quite minor and I do not want to participate in an endless "find the right name" thread. So from my point of view, please go along and take any name you like. I do like the functionality. Wim Oudshoorn. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] "prune-branch" cert implementation issues.
In message <[EMAIL PROTECTED]> on Sun, 05 Jun 2005 17:53:07 -0400, Michael Stone <[EMAIL PROTECTED]> said: mstone> I'm attempting to give people a clean way to mark a revision mstone> as "no-longer-a-head-for-branch-X". There are two use cases mstone> for a feature like this one: mstone> mstone> 1) To ignore old branches which have subsequently been merged mstone>into the mainline. I'm not sure I understand how that would work. Basically, you'd make certain branches head-less, but how does that stop anyone from updating explicitely to a specific revision (maybe even the marked revision) and continuing to work from there. Also, since this is a distributed environment, what is supposed to happen when you get revisions synced in that are children of the revision you marked as no-longer-head? To me, this seems like a moot point, or maybe a red herring. I haven't quite decided. It feels like trying to make a distributed SCM bend over backwards to behave like a centralised SCM... mstone> 2) To mark revisions as unsuitable for merging. Again, what if someone else has already done so in his/her database. What's to happen with the children? Are they supposed to end up in void? 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Workflow with Monotone
In message <[EMAIL PROTECTED]> on Mon, 6 Jun 2005 01:49:38 +0200, Wim Oudshoorn <[EMAIL PROTECTED]> said: woudshoo> Desired situation: woudshoo> woudshoo>A [project.wim] woudshoo>| \_ B [project.wim.experiment] woudshoo>C [project.wim] woudshoo> woudshoo> woudshoo> But I made a mistake and have: woudshoo> woudshoo> A [project.wim] woudshoo>/ \ woudshoo> [project.wim] C B [project.wim] woudshoo> woudshoo> and I want to fix that. monotone disapprove B monotone cert B branch project.wim.experiment cd .. monotone co --branch project.wim.experiment experiment 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Workflow with Monotone
On Sun, Jun 05, 2005 at 07:23:46PM +0200, Richard Levitte - VMS Whacker wrote: > An option is to use disapprove on B. This creates a new revision > (direkt child of B) containing the "anti-patch" of B, and you can > continue from there: > > A > | > B > | > Bd > | > C > > And if you decide that B is worth picking up again, you can update to > it and commit changes starting from it: > > A > | > B > | \ > Bd X > | > C No, this doesn't work. Part of the point of a disapprove is that it will actually kill off the changes in question. E.g., one use case is that you have A -> B, you realize B sucks, and disapprove it, while unbeknownst to you someone else has merrily updated to the latest head (B), and has committed some new changes X. Disapprove works correctly in this case; when Bd and X later get merged, the bad B changes will get stripped out of X, leaving whatever new changes were made. This is a feature. Makes this case not work right, though. What you want in this case is to disapprove the disapproval: A | B | Bd | \ C Bdd (= B) \ X -- Nathaniel -- Sentience can be such a burden. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] some basic notes on object versioning
discalimer: this may not be of any particular interest to anyone! it may also be incorrect and does not necessarily represent how monotone does or will version things. it's pretty basic and may be old news. I simply jotted down these notes the other day while thinking about things like explicit directory support and the lifetime of versioned objects. I thought that I'd post it in case someone actually finds it useful or that it might provoke some interesting discussion of how things are done currently, and how they might be done in the future. Cheers, Derek versioned objects - objects are files or directories - objects have contents - files contain data and may be empty - directories contain other objects, by name, and may also be empty - objects have attributes - eg. rwx permissions, binary type, etc. - objects have versions - computed as the sha1 hash over their contents - a directory's contents may simply be represented by the names of the objects it contains (newline separated) - objects have names - their name within their containing directory, i.e. basename(1) - names may change (i.e. rename) - objects have locations - their full path name with / separators exclusive of their name, i.e. dirname(1) - locations may change (i.e. move) - objects have lifetimes - an object's lifetime begins when it is added to its containing directory (birth) - an object's lifetime ends when the object is dropped from its containing directory (death) - an object's lifetime continues when it has name, location or content changes - the root directory exists implicitly and cannot be added, renamed, moved or dropped - the root directory only supports content changes - objects may be changed during their lifetime - name change (rename) - location change (move) - content change (file's data or directory's contained objects) - the root directory only allows content changes (it always exists and cannot be renamed or moved) - additions/deletions/renames change the directory that contains the affected objects (i.e. directory content change) revisions - any single object can undergo either a lifetime change *or* a name/location/content change in a single revision. i.e. changes after an add change what gets added, changes before a drop are essentially ignored - objects are *not* simply added or dropped, rather they are added *to* or dropped *from* some containing directory. these actions change the lifetime of the added or dropped object *and* change the *contents* of the containing directory. questions - should "add some/path/to/some/file" automatically add the intervening directories? (this seems like would probably be useful, to support recursive add in particular) - should "drop some/path/to/some/file" automatically drop the intervening directories? if they're empty? (this seems like it would probably be somewhat less useful!) - treating move and rename as different is somewhat questionable, although move seems like a somewhat better representation than rename if only one is used ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
