Re: [Monotone-devel] Future of monotone
On Sat, Feb 09, 2008 at 10:32:33AM +1100, Brian May wrote: > > "Markus" == Markus Schiltknecht <[EMAIL PROTECTED]> writes: > > Markus> ODF is an XML format, right? > > No, it is a bit more complicated then that; it is zip file containing > a number of XML files and other (possibly binary) files: > > [EMAIL PROTECTED]:~$ unzip -t hardware\ survey\ draft.ods > Archive: hardware survey draft.ods > testing: mimetype OK > testing: Configurations2/statusbar/ OK > testing: Configurations2/accelerator/current.xml OK > testing: Configurations2/floater/ OK > testing: Configurations2/popupmenu/ OK > testing: Configurations2/progressbar/ OK > testing: Configurations2/menubar/ OK > testing: Configurations2/toolbar/ OK > testing: Configurations2/images/Bitmaps/ OK > testing: content.xml OK > testing: styles.xml OK > testing: meta.xml OK > testing: Thumbnails/thumbnail.png OK > testing: settings.xml OK > testing: META-INF/manifest.xmlOK > No errors detected in compressed data of hardware survey draft.ods. So XML would have to treat this as another kind of directory, and process the files inside according to their types. But if nothing inside the zip-directory has changed, it cah detect that easily withough looking at all its component files. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Fri, Feb 08, 2008 at 11:01:59AM -0500, Peter Todd wrote: > On Fri, Feb 08, 2008 at 03:45:14PM +0100, Markus Schiltknecht wrote: > > ODF is an XML format, right? So a special XML merger would be great to > > have. However, I fear simply using a finer grained, probably even > > character based merger could even cripple your XML file - or C source > > code. So what's right is very dependent on the content, IMO. The line > > based approach simply fits source code quite well, I think. > > FWIW I'm working on a new schematic capture/pcb layout program. I know I\m > going to run into that problem and have decided to use XML fileformats and > plan > to extend existing XML merge programs to make one dedicated to the task. > > In short, write you're own merger. :) What XML mergers exist? Ive heard of two: -- one that's too slow to use for anything practically-sized, but does a robust job. -- one that relies on tree structure being largely unchanged. IIRC, It treates everything as a sequence of seqhences of sequences of ..., and assumes that nothing ever gets inserted or deleted except at the end of one of the (nested) sequences. Oh -- and nothing ever gets raised or lowered in the tree. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Fri, Feb 08, 2008 at 03:45:14PM +0100, Markus Schiltknecht wrote: > Hi, > > [EMAIL PROTECTED] wrote: > >I believe monotone uses a merge algorithm that chooses lines from the > >various ancestors. Now the trouble is that small edits in a paragraph > >can completely change the way a paragraph is split into lines. If on > >another branch a different small edit has been made, the result is a > >merge conflict. Looking at it manually to resolve the conflict, is it > >hard to even see where the actual changes have been made, because the > >differences in line division overwhelm the eye. > > That might apply to text files, but not so much to source code, which is > monotone's primary concern. Agreed. So far I haven't found anything that does a decent job with text. > > >What seems to be needed is something that recognises differences at the > >word -- or even character -- level. (When merging documents by hand, > >I'e found wdiff quite useful.) Is there any chance of getting > >something like this? > > Well, the internal merge algorithm is line based, yes. But if it decides > it cannot merge automatically due to conflicting lines, it invokes > whatever tool you want it to invoke to resolve the conflicts. Often > enough, my kdiff3 can cleanly merge everything, where monotone couldn't. > > I don't think making monotone's internal merger finer grained buys us > much. What I'd rather like to see are special, content aware mergers, > i.e. for XML or plain text, etc.. Yes. That's how I see such a feature fitting into monotone. I was hoping for something of the sort when people were discussing Windows vs Linux line endings. > > >If it could also detect blocks of text that have been moved, of course > >that would be awesome. But I suspect dealing with that is > >difficult, or it would already have been done for computer programs. > > IIRC the internal merger detects moved blocks *of lines*, yes. Interesting. I wonder how? > > >I won't even ask about proprietary word-processor formats that almost > >encrypt the data. They're beyond the pale, and I won't even consider > >using them. Stuff that can be edited with an ASCII or UTF-8 editor with > >minimal in-band markup is all I need. I suspect Open Document Format > >satisfies this description, as long as the word processor doesn't go > >overboard on overspecifying everything (too many still do). > > ODF is an XML format, right? So a special XML merger would be great to > have. However, I fear simply using a finer grained, probably even > character based merger could even cripple your XML file - or C source > code. It certainly could. Which is why I've hesitated using it on XML. Though I've heard some people are having success with it anyway. > So what's right is very dependent on the content, IMO. The line > based approach simply fits source code quite well, I think. It does. A friend of mine once decided that source code should be treated as poetry by a word processor. Lots of lines. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
> "Markus" == Markus Schiltknecht <[EMAIL PROTECTED]> writes: Markus> ODF is an XML format, right? No, it is a bit more complicated then that; it is zip file containing a number of XML files and other (possibly binary) files: [EMAIL PROTECTED]:~$ unzip -t hardware\ survey\ draft.ods Archive: hardware survey draft.ods testing: mimetype OK testing: Configurations2/statusbar/ OK testing: Configurations2/accelerator/current.xml OK testing: Configurations2/floater/ OK testing: Configurations2/popupmenu/ OK testing: Configurations2/progressbar/ OK testing: Configurations2/menubar/ OK testing: Configurations2/toolbar/ OK testing: Configurations2/images/Bitmaps/ OK testing: content.xml OK testing: styles.xml OK testing: meta.xml OK testing: Thumbnails/thumbnail.png OK testing: settings.xml OK testing: META-INF/manifest.xmlOK No errors detected in compressed data of hardware survey draft.ods. -- Brian May <[EMAIL PROTECTED]> ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: How will policy branches work?
On Feb 8, 2008 12:22 PM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > Nuno Lucas wrote: > Well, as long as no single commit spans several modules, you should > probably use separate branches per module anyway. In this case you could say they are modules, but it could be a single file on the source tree, with no clear separation between it and other source files. You can't have a branch per source file (you could but makes no sense). > > Probably this will be solved when monotone gets a proper "cherry pick" > > system. It would then be possible to "pluck" some group of revisions > > (that could be restricted by path) and retain history. > > I'm not exactly sure what you have in mind for being a "proper cherry > pick" thing. For me "cherry picking" is just what pluck does, but with an added "unpluck" option. That way you can try different patches, but have the option of "un-applying" them, for example, while chasing some regression bug. This can be done outside the DAG, with some list of changesets on the _MTN dir. You could apply/un-apply a number of "pluck like" changesets to the workspace and the information about the used changesets saved somewhere on _MTN. An extreme example of "cherry picking" is git bissect command. You could have the some functionality on monotone if people could also "unpluck" a changeset. To me is not that important that a full DAG relationship (a graph edge betwen revisions) is actually stored. The automatic comment added when pluck is used can be enough (as long as the user can edit it latter to add/remove as much more detail he wish). If a special cert could be added with the operation detail, to be used by GUI programs, not monotone itself, better. Off course all this could be made simpler to the user by having more helper commands, like (names for demonstration purpose, only): - "ls patches", to list the changesets currently stored, a local id and tell if applied; - "push " to add a changeset to the list (pluck on steroids); - "pop " to remove a changeset from the list (and eventually un-apply or just tell user to first manually un-apply it); - "apply " to apply one of the changesets on the list; - "un-apply " to un-apply a specific changeset from the workspace. By allowing "apply" and "un-apply" to indicate a range, one could easily implement bisect using a shell script. Well, talk is easy and as I will not implement this myself (at least not in the near term) I believe I should shut up now ;-) Best regards, ~Nuno Lucas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Revision Control Debate
Cool, thank you for the pointer. I've added some supportive arguments for monotone. Thank you Markus, as well as lapo and willu for insightful points under Monotone. I want to expand this debate further by getting the experts in the field to chime in. Secondly, we are planning a podcast roundtable session to accompany the answers to this question , and if anyone in this list would like to participate for monotone, please contact me at [EMAIL PROTECTED] or respond here. We are scheduling it for early next week. Hm.. I don't feel like I am the right person for that, sorry. No worries. I will find someone or I may let the discussion build further. I have someone from git community, but still looking for some more people from other projects. Cheers, Curtis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Fri, Feb 08, 2008 at 03:45:14PM +0100, Markus Schiltknecht wrote: > ODF is an XML format, right? So a special XML merger would be great to > have. However, I fear simply using a finer grained, probably even > character based merger could even cripple your XML file - or C source > code. So what's right is very dependent on the content, IMO. The line > based approach simply fits source code quite well, I think. FWIW I'm working on a new schematic capture/pcb layout program. I know I\m going to run into that problem and have decided to use XML fileformats and plan to extend existing XML merge programs to make one dedicated to the task. In short, write you're own merger. :) -- http://petertodd.org signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
Hi, [EMAIL PROTECTED] wrote: I believe monotone uses a merge algorithm that chooses lines from the various ancestors. Now the trouble is that small edits in a paragraph can completely change the way a paragraph is split into lines. If on another branch a different small edit has been made, the result is a merge conflict. Looking at it manually to resolve the conflict, is it hard to even see where the actual changes have been made, because the differences in line division overwhelm the eye. That might apply to text files, but not so much to source code, which is monotone's primary concern. What seems to be needed is something that recognises differences at the word -- or even character -- level. (When merging documents by hand, I'e found wdiff quite useful.) Is there any chance of getting something like this? Well, the internal merge algorithm is line based, yes. But if it decides it cannot merge automatically due to conflicting lines, it invokes whatever tool you want it to invoke to resolve the conflicts. Often enough, my kdiff3 can cleanly merge everything, where monotone couldn't. I don't think making monotone's internal merger finer grained buys us much. What I'd rather like to see are special, content aware mergers, i.e. for XML or plain text, etc.. If it could also detect blocks of text that have been moved, of course that would be awesome. But I suspect dealing with that is difficult, or it would already have been done for computer programs. IIRC the internal merger detects moved blocks *of lines*, yes. I won't even ask about proprietary word-processor formats that almost encrypt the data. They're beyond the pale, and I won't even consider using them. Stuff that can be edited with an ASCII or UTF-8 editor with minimal in-band markup is all I need. I suspect Open Document Format satisfies this description, as long as the word processor doesn't go overboard on overspecifying everything (too many still do). ODF is an XML format, right? So a special XML merger would be great to have. However, I fear simply using a finer grained, probably even character based merger could even cripple your XML file - or C source code. So what's right is very dependent on the content, IMO. The line based approach simply fits source code quite well, I think. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Tue, Jan 29, 2008 at 09:30:24AM -0800, [EMAIL PROTECTED] wrote: > On Mon, Jan 28, 2008 at 05:04:33PM +0100, Markus Schiltknecht wrote: > > > Thomas Keller wrote: > > >So where lacks monotone the most? There's the question of editing files. Normal (say) English text, divided into paragraphs. It's not unusual for a document to fork into several versions, even when maintained by a single author, for which corrections have to be propagated -- the usual problem for which revision control is the answer. I believe monotone uses a merge algorithm that chooses lines from the various ancestors. Now the trouble is that small edits in a paragraph can completely change the way a paragraph is split into lines. If on another branch a different small edit has been made, the result is a merge conflict. Looking at it manually to resolve the conflict, is it hard to even see where the actual changes have been made, because the differences in line division overwhelm the eye. It's possible to avoid the variations in line division by adopting a convention wherby in the file itself you only use explicit newlines between paragraphs, relying on the editor, or printing software to use sensible formatting for long lines. (this is a small step in the direction of a sensible word processor). But then the lines become very long in themselves, and, although variations in layout will no longer result in differences to be resolved, any changes that do occur are lost in even more unchanged text. The practical result is much the same as with the previous regime. What seems to be needed is something that recognises differences at the word -- or even character -- level. (When merging documents by hand, I'e found wdiff quite useful.) Is there any chance of getting something like this? If it could also detect blocks of text that have been moved, of course that would be awesome. But I suspect dealing with that is difficult, or it would already have been done for computer programs. I won't even ask about proprietary word-processor formats that almost encrypt the data. They're beyond the pale, and I won't even consider using them. Stuff that can be edited with an ASCII or UTF-8 editor with minimal in-band markup is all I need. I suspect Open Document Format satisfies this description, as long as the word processor doesn't go overboard on overspecifying everything (too many still do). -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: How will policy branches work?
Hi, Nuno Lucas wrote: I see the problem now. Seems like the simple way of solving it may be by introducing helper revisions. But that could clutter the repository with no apparent gain, aside more history. OTOH, I somehow missed the path restriction option on "mtn pluck". Maybe it wasn't there the first time it was introduced? Uh.. looks like the manual also doesn't know, yet. Haven't tried it yet, but it will always be better than using an external diff/patch cycle. Not much, IMO, because with regard to history, it looks almost the same. The only benefit pluck gives to diff/patch, is properly tracking renames. However, unlike with propagate, you have to track manually what you've merged and what not. As this is some form of "cherry picking", that's probably what you want in that case. I'm rather thinking, that changes to such modules should be committed separately, anyway. Thus, they can separately be merged by the people who know how to merge them. Those who don't shouldn't be forced to do the merge, yes. They don't have to. But they also shouldn't be forced to cope with partly merged revisions. The problem is not with separate commits, but with commits inter spaced with other commits to other files on the workspace, meaning there isn't a linear serie of changesets only touching those files. Well, as long as no single commit spans several modules, you should probably use separate branches per module anyway. Additionally, you can use explicit_merge to some extent, to only do the merges you actually want to do. However, you are right in that that's tedious, because monotone forces the "older" merge to be done first. An example, to make sure we speak about the same things: A (touching files in modules: foo and bar) /\ / \ B C (touching (touching bar) bar) | | | | | | D E (touching (touching foo) foo) In such a case, the developers who are working on module foo cannot merge revisions D and E, without also having to merge B and C. My argument was, that the developers of module bar can explicit_merge revisions B and C (instead of D and E, having to do all of the merge) and then let the foo developers merge their changes. But it's a little bit more complicated, because after the foo developers have explicitly merged C and D, we have three heads: A / \ B C |\ /| D F E If the developers of module foo try to merge D and E, they will have to redo the merge of B and C. Instead, they should first merge D and F, then E and F, both of which should be clean merges, resulting in two heads, G and H: A / \ B C |\ /| D F E \/ \/ G H Only after that, they can do "their" merging, by merging G and H, without having to bother about module bar. Probably this will be solved when monotone gets a proper "cherry pick" system. It would then be possible to "pluck" some group of revisions (that could be restricted by path) and retain history. I'm not exactly sure what you have in mind for being a "proper cherry pick" thing. However, being able to do path restricted merges would result in different DAGs per path restriction, no? Let's check our example and assume both groups of developers do their merges, restricted to paths. We would end up with: A / \ B C |\ /| D I E \ / K Revisions I and K were merged with a path restriction to module bar and foo, respectively. So, overall, we now have four heads: I (for files in module bar), K (for files in module foo) and D and E (for all other files). I've drawn I with ancestors B and C, because those are the "heads" for the path restriction in question. This gives us the advantage of getting a full revision, instead of a path restricted one. Of course - as above - merging them in the right order gives you all clean merges and a single head. (This would maybe speak for letting monotone merge everything it can merge cleanly.) However, merging in presence of path restricted revisions doesn't exactly sound trivial. Assuming you cannot merge two restricted revisions, but only a full revision with a restricted one, the right order here would be: * merge D+I to L, and E+I to M * merge M+L to N * merge K+N to O Not to mention, that the user interface for such "path restricted revisions" would become quite complicated and confusing, I think. Or how do you plan t
Re: [Monotone-devel] ..more notes about .nuskool
Hi, Zbigniew Zagórski wrote: Just for curiosity how big databases you've managed to sync ? Is it useful for syncing n.v.monotone* branch set ? Uh.. nuskool isn't quite there, yet, sorry. With the oldskool netsync, I'm regularly synching a database over 500mb. Maybe a little not related opinion. I've been thinking a lot about all of this while hacking on n.v.m.dumb. I know that current dumb tool can be much more faster if it would be possible to retrieve complete merkle_dir (or anything representing state of the database/project) in some fast way. The HTTP time wasn't too important, the most time consuming was retrieving/toposorting all revisions (not so bad) and all the certs for all revisions (ages). I would like to bring together nuskool and nvm.dumb. Maybe even integrate compatibility to download from dumb servers into monotone. However, the primary point of nuskool is not requiring to build merkle tries anymore. Instead, it uses a DAG based refinement [1], as do most other similar VCSes. So nvm.dumb will probably have to adapt as well. It's slow also for current netsync protocol so I think there must be some idea shift about synchronization. How to synchronize databases without retrieving WHOLE of tree and ALL certs. Well, without a merkle trie, certs will have to be treated differently. Graydon proposed a DAG based synchronization for the certs as well. This would involve creating revisions in "cert branches" - somewhat similar to policy branches. I still need to get my mind around that, but it sounds very interesting to me. See the IRC log here [2]. Regards Markus [1]: Monotone wiki about DAG based refinement: http://www.venge.net/mtn-wiki/DagBasedRefinement [2]: Monotone IRC log: http://colabti.de/irclogger/irclogger_log/monotone?date=2008-01-31,Thu#l51 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ..more notes about .nuskool
2008/2/4, Markus Schiltknecht <[EMAIL PROTECTED]>: > However, ATM nvm.nuskool is pretty simplistic and works over HTTP > exclusively, ignoring any branch patterns and synchronizing all > revisions in the database. Just for curiosity how big databases you've managed to sync ? Is it useful for syncing n.v.monotone* branch set ? > I'd like to go for something more RESTful, as far as the HTTP interface > is concerned. This should make better use of the HTTP caching > infrastructure and would probably even allow something like the "mtn > dumb" server interface. > > If we still need olskool netsync (do we?), we should encapsulate the > communication channel stuff from the nuskool new DAG based refinement > thingie, very much like the current refiner is separate. >... > > 1.) sync from mtn client to dumb http server with static files > 2.) sync from mtn client to clever http server via scgi to mtn server > 3.) sync from mtn client to clever mtn server via netsync > > While the first two require a state-less approach, fitting HTTP, the > third option doesn't. I'm not sure if it's worth exploiting that. > Probably not. And the first option is quite different in that we cannot > put any logic into the server, for obvious reasons. Maybe a little not related opinion. I've been thinking a lot about all of this while hacking on n.v.m.dumb. I know that current dumb tool can be much more faster if it would be possible to retrieve complete merkle_dir (or anything representing state of the database/project) in some fast way. The HTTP time wasn't too important, the most time consuming was retrieving/toposorting all revisions (not so bad) and all the certs for all revisions (ages). It's slow also for current netsync protocol so I think there must be some idea shift about synchronization. How to synchronize databases without retrieving WHOLE of tree and ALL certs. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: How will policy branches work?
On Feb 7, 2008 7:16 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > > By the way, I don't see as this is any different than what is already > > done by a 3-way merge with user editings. It's not the original > > revision either. > > Well, the difference is, with a 3-way merge, you are saying: my newly > merged revision X is the successor of A and B - in all files. > > Here, you would need something like: revision X is the successor of A > and B only for files in "libs/*". For files outside that restriction, > there shouldn't be any preference (i.e. could still be A or B). I see the problem now. Seems like the simple way of solving it may be by introducing helper revisions. But that could clutter the repository with no apparent gain, aside more history. OTOH, I somehow missed the path restriction option on "mtn pluck". Maybe it wasn't there the first time it was introduced? Haven't tried it yet, but it will always be better than using an external diff/patch cycle. > I'm rather thinking, that changes to such modules should be committed > separately, anyway. Thus, they can separately be merged by the people > who know how to merge them. Those who don't shouldn't be forced to do > the merge, yes. They don't have to. But they also shouldn't be forced to > cope with partly merged revisions. The problem is not with separate commits, but with commits inter spaced with other commits to other files on the workspace, meaning there isn't a linear serie of changesets only touching those files. Probably this will be solved when monotone gets a proper "cherry pick" system. It would then be possible to "pluck" some group of revisions (that could be restricted by path) and retain history. Regards, ~Nuno Lucas > > Regards > > Markus > > ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Re: Re: Re: How will policy branches work?
On Fri, 08 Feb 2008 03:20:40 +0200, Brian May <[EMAIL PROTECTED]> wrote: "Boris" == Boris <[EMAIL PROTECTED]> writes: Boris> The problem is the co-worker shouldn't be allowed to check out the Boris> files at all. Management doesn't want anyone else except the Boris> responsible developers to see the source code. That would need to be Boris> guaranteed by the version control system - easy if it's a centralized Boris> one, arguably more difficult if it's a distributed one. I don't know Boris> if this will ever be possible with monotone (I don't even know if Boris> such a scenario is supported by any other distributed version control Boris> sytem) but these are the requirements I face. :) Maybe I missed something, but do you realize you can control what branches people are allowed to *read* from a server? Yes, you missed something. :) I also need to control what people send each other when they synchronize their databases without the central server - at least to a certain extent. Boris ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Revision Control Debate
Hello Curtis, Curtis Spencer wrote: We currently have a question on there about which VCS to use on a new open source project: http://www.cruxlux.com/question/view/1095 and it would be cool to get some monotone supporters in there. Cool, thank you for the pointer. I've added some supportive arguments for monotone. I want to expand this debate further by getting the experts in the field to chime in. Secondly, we are planning a podcast roundtable session to accompany the answers to this question , and if anyone in this list would like to participate for monotone, please contact me at [EMAIL PROTECTED] or respond here. We are scheduling it for early next week. Hm.. I don't feel like I am the right person for that, sorry. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Re: Future of monotone
Hi, Brian May wrote: Presumably, another option might be to suspend the branch. Killing the revision won't work if others have already sync'd it. Hm.. agreed. Note that suspend cert will also get propagated to Abe, who might or might not like that cert much (depending if he committed accidentally or by intention). That's one of the problems policy branches should solve, IMO. ;-) Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
