Re: [Monotone-devel] mtn2git issues
Felipe Contreras schrieb: Then I tried get_manifest_of, however, that is very slow. And even if it wasn't, it would require a considerable amount of processing and store every tree of every revision. Do you have any recommendation on how to get what changed in each revision? Surely it must not be that difficult. Did you try rosters? They're an internal representation of manifests (with some differences, they contain some data specific to the local repository, which you might not care about), and they're also stored in delta format, like manifests. Maybe access is still faster (because they don't need as much validation, as far as I know) For git, you want to know how the tree looked at specific times (snapshots), but the native data exchange format in monotone is changesets (what you get with get_revision - it tells you what changed from rev A to rev B, and in merge scenarios, to each side the whole other side happened, to get to the merged result). Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller [EMAIL PROTECTED] writes: Quite a lot of time (4+ months) passed by since 0.40 was released and a couple of things have been implemented and fixed since then. Though there are no big highlights, I'd still like to do a release just to show that we're still alive. The buildbots (at least those which are working) look reasonable green - the freebsd one has a not enough memory problem, some seem to be offline, but the rest looks ok. I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. This is the biggest impediment to using mtn for my team at work; they are scared of merging, because of the uncertainty involved in the conflict resolution process. This is especially true for propagating between branches; there are typically many small conflicts that must be reviewed. All of the code I need is in n.v.m.automate_show_conflicts, which also implements suture (but not fully yet). I'm subsetting that into n.v.m.resolve_conflicts (yes, the branch names are not the best). Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. So if we can postpone a release until next weekend, I'd appreciate it. On the other hand, the mtn command line interface to this feature is not at all settled. I'm implementing this process: mtn automate show_conflicts _MTN/conflicts add resolutions to MTN/conflicts via Emacs DVC GUI mtn merge --resolve-conflicts-file MTN/conflicts Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. This minimal command line interface is sufficient to get things started; we can add more commands for the next release, after people have had a chance to experiment. We can also add resolutions for more conflicts. In the meantime, any text editor can be used to add resolutions to the conflict file; it's in basic-io format. However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn2git issues
On Sun, Aug 31, 2008 at 9:24 AM, Patrick Georgi [EMAIL PROTECTED] wrote: Felipe Contreras schrieb: Then I tried get_manifest_of, however, that is very slow. And even if it wasn't, it would require a considerable amount of processing and store every tree of every revision. Do you have any recommendation on how to get what changed in each revision? Surely it must not be that difficult. Did you try rosters? They're an internal representation of manifests (with some differences, they contain some data specific to the local repository, which you might not care about), and they're also stored in delta format, like manifests. Maybe access is still faster (because they don't need as much validation, as far as I know) For git, you want to know how the tree looked at specific times (snapshots), but the native data exchange format in monotone is changesets (what you get with get_revision - it tells you what changed from rev A to rev B, and in merge scenarios, to each side the whole other side happened, to get to the merged result). Well, this is for git fast-import. So I want the changes of each revision. The only difference is that in git the changes in both branches of a merge are 'already done' so you can't do them again. So I guess what fast-import is doing is taking the changes strictly of the merge, and then the rest of the files are taken from the parents. -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn2git issues
Felipe Contreras [EMAIL PROTECTED] writes: On Sun, Aug 31, 2008 at 9:24 AM, Patrick Georgi [EMAIL PROTECTED] wrote: The only difference is that in git the changes in both branches of a merge are 'already done' so you can't do them again. So I guess what fast-import is doing is taking the changes strictly of the merge, and then the rest of the files are taken from the parents. The problem is defining what files were changed strictly by the merge. I suspect this means files that were modified from the common ancestor in both parents, and thus needed file merging during the revision merge. You can identify such files in the output of get_revision; they are the ones that appear in both changesets. However, if the result of the file merge is identical to one of the parents (due to user choices during the file merge), then maybe it's not considered modified during the merge? So you have to look at the file ids, and compare them to the file ids in the parent revisions. I don't see an operation for that in mtn automate; it would be something like: mtn automate get_file_id revision filename or maybe (slightly faster): mtn automate get_corresponding_file_id current_revision file_id revision -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn2git issues
On Sun, Aug 31, 2008 at 12:01 PM, Felipe Contreras [EMAIL PROTECTED] wrote: On Sun, Aug 31, 2008 at 9:24 AM, Patrick Georgi [EMAIL PROTECTED] wrote: Felipe Contreras schrieb: Then I tried get_manifest_of, however, that is very slow. And even if it wasn't, it would require a considerable amount of processing and store every tree of every revision. Do you have any recommendation on how to get what changed in each revision? Surely it must not be that difficult. Did you try rosters? They're an internal representation of manifests (with some differences, they contain some data specific to the local repository, which you might not care about), and they're also stored in delta format, like manifests. Maybe access is still faster (because they don't need as much validation, as far as I know) For git, you want to know how the tree looked at specific times (snapshots), but the native data exchange format in monotone is changesets (what you get with get_revision - it tells you what changed from rev A to rev B, and in merge scenarios, to each side the whole other side happened, to get to the merged result). Well, this is for git fast-import. So I want the changes of each revision. The only difference is that in git the changes in both branches of a merge are 'already done' so you can't do them again. So I guess what fast-import is doing is taking the changes strictly of the merge, and then the rest of the files are taken from the parents. I forgo to mention that I didn't try rosters. I assumed get_manifest_of would use them. -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn2git issues
On Sun, Aug 31, 2008 at 3:55 PM, Stephen Leake [EMAIL PROTECTED] wrote: Felipe Contreras [EMAIL PROTECTED] writes: On Sun, Aug 31, 2008 at 9:24 AM, Patrick Georgi [EMAIL PROTECTED] wrote: The only difference is that in git the changes in both branches of a merge are 'already done' so you can't do them again. So I guess what fast-import is doing is taking the changes strictly of the merge, and then the rest of the files are taken from the parents. The problem is defining what files were changed strictly by the merge. I suspect this means files that were modified from the common ancestor in both parents, and thus needed file merging during the revision merge. You can identify such files in the output of get_revision; they are the ones that appear in both changesets. Yes, I'm trying your suggestion right now. Good idea. However, if the result of the file merge is identical to one of the parents (due to user choices during the file merge), then maybe it's not considered modified during the merge? So you have to look at the file ids, and compare them to the file ids in the parent revisions. I don't see an operation for that in mtn automate; it would be something like: mtn automate get_file_id revision filename or maybe (slightly faster): mtn automate get_corresponding_file_id current_revision file_id revision Right now I'm fetching the whole contents of the file anyway, git would check if the file has changed or not. In order compare the file ids of a revision to the parents I would have to either a) keep the whole tree of every revision, or b) use get_file_id for the revision and both parents. I assume it would be more efficient to do b), but would 3 calls to get_file_id be more efficient than just grabbing the whole file contents? Maybe a get_revision_changes command would make sense; it does the 3 get_file_id gets, makes the comparison and generates a stripped down version. -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: mtn2git issues
Felipe Contreras wrote: Right now I'm fetching the whole contents of the file anyway, git would check if the file has changed or not. Then you can easily have the file id, that is (currently) the SHA-1 of the file... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn2git issues
On Sun, Aug 31, 2008 at 6:01 PM, Lapo Luchini [EMAIL PROTECTED] wrote: Felipe Contreras wrote: Right now I'm fetching the whole contents of the file anyway, git would check if the file has changed or not. Then you can easily have the file id, that is (currently) the SHA-1 of the file... I would have to get the file contents of the revision and the parents. But let's not forget why I want the file id: to see if I should retrieve the file and send it to git, or not. I would rather just send it to git and let it find out if it changed or not. -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Ludovic Brenta schrieb: Thomas Keller writes: So please check NEWS if it contains a note of something you may have done to trunk since 0.40 Speaking of NEWS, it appears that the introduction of suspension certs is documented nowhere in it. I don't even remember what version that was. Could someone please add the appropriate entry, even if that means rewriting history? Well, I guess we don't like to rewrite history, but I added an entry for mtn suspend under 0.41 noting that we've forgot to mention it for 0.37... Thanks for the reminder! Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Stephen Leake schrieb: Thomas Keller [EMAIL PROTECTED] writes: Quite a lot of time (4+ months) passed by since 0.40 was released and a couple of things have been implemented and fixed since then. Though there are no big highlights, I'd still like to do a release just to show that we're still alive. The buildbots (at least those which are working) look reasonable green - the freebsd one has a not enough memory problem, some seem to be offline, but the rest looks ok. I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. So if we can postpone a release until next weekend, I'd appreciate it. If the others are ok, I guess we can easily release a few days later. (After all, we've already waited four months...) My wife and son are away from Wednesday, so I guess I'll have more time for different things then anways ;) On the other hand, the mtn command line interface to this feature is not at all settled. I'm implementing this process: mtn automate show_conflicts _MTN/conflicts add resolutions to MTN/conflicts via Emacs DVC GUI mtn merge --resolve-conflicts-file MTN/conflicts Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. A usable command line would probably be needed, otherwise people which don't use Emacs (like me) will find the interface then pretty academic and won't use it. This minimal command line interface is sufficient to get things started; we can add more commands for the next release, after people have had a chance to experiment. We can also add resolutions for more conflicts. In the meantime, any text editor can be used to add resolutions to the conflict file; it's in basic-io format. However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... Other opinions? Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Monday 01 September 2008 Thomas Keller wrote: Stephen Leake schrieb: I'm working on a minimal implementation of conflict resolution; just content and duplicate name conflicts. The duplicate name resolutions will only be rename or drop, not suture. The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? It should, or at least I would be surprised if it didn't. Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. Do all tests pass? I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. So if we can postpone a release until next weekend, I'd appreciate it. While a review could be done in a week, I'm not sure we should really be in a hurry. We can easily have a 0.42 in a month or so. On the other hand, the mtn command line interface to this feature is not at all settled. I'm implementing this process: mtn automate show_conflicts _MTN/conflicts add resolutions to MTN/conflicts via Emacs DVC GUI mtn merge --resolve-conflicts-file MTN/conflicts Others have expressed a desire for mtn command line operations to add resolutions to the conflict file. I don't plan on using them, and we did not come to any consensus on what they might be, so I'm not implementing them now. A usable command line would probably be needed, otherwise people which don't use Emacs (like me) will find the interface then pretty academic and won't use it. Yes, I also think that a cmdline interface for recording resolving decisions is needed. Not everyone is using emacs. At least the format of MTN/conflicts must be documented properly. Also, test cases are needed. (Maybe this is already done, didn't find the time yet to have a look at that branch). However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... Other opinions? Not meaning to discourage you, Stephen, but at this time, and with Thomas wearing the release manager cap already, I'd say, we'd better have 0.41 done now, and have your work merged in afterward. Having a 0.42 release within short time then would be fine and fully justified even by a single new feature. But of course the decision is up to Thomas as he's doing the work ;) - Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller schrieb: The point of this conflict resolution implementation is to allow preparing conflict resolutions one at a time, before the actual merge command is issued. Then when you do the merge, you can tell it to use the prepared resolutions, so no user interaction is necessary. This avoids the problem of losing work when you encounter a conflict that's complicated and abort a merge. That sounds pretty cool already. Does this work for workspace merge as well, i.e. update? Sorry, I read for show_conflicts now in 0.40 that this is currently not possible - probably because the revision does not yet exists in database. Probably a harder task...? Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't change any core monotone data structures or database formats, so it should not break any current functionality. I plan to get it done this weekend (Monday included; it's a holiday here in the US). I'd like this to be in the next release so my team at work can use it, without an internal mtn version. I'd definitely like to have some people look over the code before it gets merged. A few small objections (without being dived too deep into the code tonight): I created two small conflicts and tried to merge via mtn merge --resolve-conflicts-file _MTN/conflicts. I did not edit the file yet, so I supposed an error resolution entry missing or something, but I rather got an invariant: roster_merge.cc:1715: invariant 'I(result.attribute_conflicts.size() == 0)' violated As long as we have no user UI this and probably other invariants should become user errors, no? Secondly, there is a FIXME in monotone.texi: FIXME_RESOLVE_CONFLICTS: – added default resolution for file content conflicts Thirdly, I'm missing documentation on the format of conflict resolution stanzas (beside resolved_internal nothing is mentioned) - this and maybe a small example / test workflow could be added to the manual for now? However, if people want more of a chance to review this stuff before merging it to main for a release, or want to wait for a more complete implementation, that's fine, too. I'm undecided - even though I wear this nice release manager hat, I don't like to say just yes or no here. I perfectly understand that you need it for your team and that people should be encouraged testing it and all, but I fear that once the code went into mainline, the general (your?) interest making a halfway usable command line which does not include editing basic_io files is gone by then... I think I'd go for a compromise: Review the current changes more closely in nvm.resolve-conflicts - if all goes well and it gets merged, we release 0.41 with your branch. If not or any major dealbreakers are found within the next days, we release 0.41 without your branch. Timeline is still until next weekend, if we get ready sooner, we can release earlier - but there will be no later release than next sunday. Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
