[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
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
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
[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] 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
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
