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] mtn2git issues
"Zack Weinberg" <[EMAIL PROTECTED]> writes: > On Sat, Aug 30, 2008 at 4:46 PM, Felipe Contreras > <[EMAIL PROTECTED]> wrote: >> I've been working on a mtn2git script and I've been having many issues. >> >> What git requires is very simple; a list of the files that changed >> (added, modified, renamed, removed) in each revision. > ... >> When a merge happens, get_revision is listing all the changes (the >> changes from both branches), not the changes that happened strictly of >> that revision. > ... >> Do you have any recommendation on how to get what changed in each >> revision? Surely it must not be that difficult. > > I don't understand what you mean by "the changes that happened > strictly of that revision"; or rather, I don't understand how it can > be a different thing from what you get from get_revision. Relative to > one merge parent, one of the changesets applies; relative to the > other, the other changeset applies. If you discard any of that > information you can't represent the merge correctly. Files that were modified from the common ancestor in both parents are changed by the merge operation, and are thus different from both parents; perphaps that is what is meant. You can identify such files in the output of get_revision; they are the ones that appear in both changesets. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn2git issues
On Sat, Aug 30, 2008 at 4:46 PM, Felipe Contreras <[EMAIL PROTECTED]> wrote: > I've been working on a mtn2git script and I've been having many issues. > > What git requires is very simple; a list of the files that changed > (added, modified, renamed, removed) in each revision. ... > When a merge happens, get_revision is listing all the changes (the > changes from both branches), not the changes that happened strictly of > that revision. ... > Do you have any recommendation on how to get what changed in each > revision? Surely it must not be that difficult. I don't understand what you mean by "the changes that happened strictly of that revision"; or rather, I don't understand how it can be a different thing from what you get from get_revision. Relative to one merge parent, one of the changesets applies; relative to the other, the other changeset applies. If you discard any of that information you can't represent the merge correctly. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] mtn2git issues
Hi, I've been working on a mtn2git script and I've been having many issues. What git requires is very simple; a list of the files that changed (added, modified, renamed, removed) in each revision. First I tried get_revision which is very fast, however, the output is not exactly what I want. When a merge happens, get_revision is listing all the changes (the changes from both branches), not the changes that happened strictly of that revision. 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. Best regards. -- 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
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? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Sat, Aug 30, 2008 at 5:23 AM, Thomas Keller <[EMAIL PROTECTED]> wrote: > 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. "make distcheck" is failing because it can't find a rule to create "mtnopt". This is a script which comes with the source tree; I tried renaming it out of the util/ directory but that did not help. Whoever created that file, please fix this. > if everything looks reasonable sane, I'd do a release sometime on sunday. I've also done a couple of small updates to the Debian packaging. Please DO NOT follow the instructions in upgrade-checklist.txt for modifying debian/changelog; instead just do $ dch -m --release and then immediately quit out of the editor. If you do not have access to the "dch" utility, just change the word "UNRELEASED" to "unstable" on the first line of debian/changelog, and replace the date after my email address with the current time (you can use "date -R" to get it in the right format). Note that there must be two spaces between the email address and the date. I'll handle debian packaging/upload from there. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Time for a release
Hi all! 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. If Richard is too busy right now, I'd do the release manager work this time, if he's ok with that. So please check NEWS if it contains a note of something you may have done to trunk since 0.40, especially check the spelling there (I'm not a native, so I may have overlooked something) - if everything looks reasonable sane, I'd do a release sometime on 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
