Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?
Am 09.01.11 12:34, schrieb CooSoft Support: > I have probably completely misunderstood but... > > If I understand you correctly your multimap would store the raw output > of the diff. Could one not store the essential arguments to the > dump_diff() call instead of the diff output (say the two paths and file > ids but _not_ the file content (which can easily be retrieved when > needed))? Then iterate through your sorted multimap calling get_data(), > lua.hook_get_encloser_pattern() and lastly dump_diff(). That way each > node in the multimap would contain a lot less data than a diff output, > addressing Richard's concern, and it would also mean that you wouldn't > have to worry about capturing the output of external diff operations as > they would be done in order and not require sorting. Right, I could create a small temporary struct for that, I just hope I don't go tabula rasa with the other code around. Lets see how it works out - thanks for all your input. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Quick poll: Does anybody actually still use diff with --external?
I have probably completely misunderstood but... If I understand you correctly your multimap would store the raw output of the diff. Could one not store the essential arguments to the dump_diff() call instead of the diff output (say the two paths and file ids but _not_ the file content (which can easily be retrieved when needed))? Then iterate through your sorted multimap calling get_data(), lua.hook_get_encloser_pattern() and lastly dump_diff(). That way each node in the multimap would contain a lot less data than a diff output, addressing Richard's concern, and it would also mean that you wouldn't have to worry about capturing the output of external diff operations as they would be done in order and not require sorting. Anyway what ever you decide +1 from me as well... :-) Cheers, Tony. Thomas Keller wrote: I don't say its impossible to do, but it would require quite a lot more code shuffling. If you look at the actual implementation in cmd_diff_log.cc, around line 120, you see that we have to keep quite a lot of state during a potential "first" round in order to sort things before we go on with the "second" round which calculates and outputs the actual diff. In the end I'm just up for fixing this one bug, issue 102, so if you think there is an easier / better way to do it, be my guest :) Thomas. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?
Thomas Keller writes:
> Am 08.01.11 08:30, schrieb Richard Levitte:
>> In message <4d27b530.1080...@thomaskeller.biz> on Sat, 08 Jan 2011 01:52:00
>> +0100, Thomas Keller said:
>>
>> me> I'm working on issue 102 and to make this work properly I want to
>> me> create the diff output and return it instead of just printing it
>> me> to stdout directly. Problem is that the external diff hook calls
>> me> execute("diff", "-u", ...) and I wonder if I should go through the
>> me> hassle and use spawn_redirected to catch and return the output
>> me> from there.
>>
>> I'm not sure what you're about to do... it does sound like you want
>> to create the whole diff in memory and output it when it's complete.
>
> Yes, this was my intention. See
> https://code.monotone.ca/p/monotone/issues/102/#ic315.
>
>> In my opinion, that would be a bad idea (think huge diffs), and I'm
>> not quite sure how that would fix the sorting order, which is the
>> actual issue here. Maybe I misunderstand what you're thinking of
>> doing...
>
> Well, my plan was to use the parallel node iterator to produce a diff
> for all changed nodes and save the results to a multimap. Then I'd
> iterate over this multimap and output the actual diff.
The comment in issue 102 implies that you _can't_ sort the diffs before
they are generated, because you need old and new paths in some cases. Or
at least, using your approach is the simplest/smallest modification to
get the sorting.
Works for me.
So +1 for your approach and for deleting --external.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?
Am 08.01.11 14:54, schrieb CooSoft Support: > Works + spanner spring to mind with my reply :-) > > Personally I couldn't care less that the au diff command doesn't have > the --external option and I have never thought it inconsistent as one > would only use it via some other tool like mtn-browse and if you wanted > to use say kompare or kdiff3 then it is easy enough for something like > mtn-browse to do that by fetching the files and doing it manually > (mtn-browse actually does that). > > However on the ordinary mtn diff command I do have --external set up to > use kompare and that can prove very useful when comparing complex > unchecked in changes made inside a workspace. Easily got round with a > script though, automating what Stephen suggested, so certainly not `a > must have'. > > But I must admit I don't see the connection between the question and the > diff sort order. Wouldn't diff be called per file so isn't it just the > file order that needs sorting first? Also how does removing it make > things faster? I don't say its impossible to do, but it would require quite a lot more code shuffling. If you look at the actual implementation in cmd_diff_log.cc, around line 120, you see that we have to keep quite a lot of state during a potential "first" round in order to sort things before we go on with the "second" round which calculates and outputs the actual diff. In the end I'm just up for fixing this one bug, issue 102, so if you think there is an easier / better way to do it, be my guest :) Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Quick poll: Does anybody actually still use diff with --external?
Am 08.01.11 08:30, schrieb Richard Levitte:
> In message <4d27b530.1080...@thomaskeller.biz> on Sat, 08 Jan 2011 01:52:00
> +0100, Thomas Keller said:
>
> me> I'm working on issue 102 and to make this work properly I want to
> me> create the diff output and return it instead of just printing it
> me> to stdout directly. Problem is that the external diff hook calls
> me> execute("diff", "-u", ...) and I wonder if I should go through the
> me> hassle and use spawn_redirected to catch and return the output
> me> from there.
>
> I'm not sure what you're about to do... it does sound like you want
> to create the whole diff in memory and output it when it's complete.
Yes, this was my intention. See
https://code.monotone.ca/p/monotone/issues/102/#ic315.
> In my opinion, that would be a bad idea (think huge diffs), and I'm
> not quite sure how that would fix the sorting order, which is the
> actual issue here. Maybe I misunderstand what you're thinking of
> doing...
Well, my plan was to use the parallel node iterator to produce a diff
for all changed nodes and save the results to a multimap. Then I'd
iterate over this multimap and output the actual diff.
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Quick poll: Does anybody actually still use diff with --external?
Works + spanner spring to mind with my reply :-)
Personally I couldn't care less that the au diff command doesn't have
the --external option and I have never thought it inconsistent as one
would only use it via some other tool like mtn-browse and if you wanted
to use say kompare or kdiff3 then it is easy enough for something like
mtn-browse to do that by fetching the files and doing it manually
(mtn-browse actually does that).
However on the ordinary mtn diff command I do have --external set up to
use kompare and that can prove very useful when comparing complex
unchecked in changes made inside a workspace. Easily got round with a
script though, automating what Stephen suggested, so certainly not `a
must have'.
But I must admit I don't see the connection between the question and the
diff sort order. Wouldn't diff be called per file so isn't it just the
file order that needs sorting first? Also how does removing it make
things faster?
In short - no real objections but I think it would be a pity and I can't
see what it would gain other than simplification. Also other SCM tools
allow for the integration of external/other comparison tools so may be a
bit of a negative on the `features' front.
Tony.
Thomas Keller wrote:
I'm working on issue 102 and to make this work properly I want to create
the diff output and return it instead of just printing it to stdout
directly. Problem is that the external diff hook calls execute("diff",
"-u", ...) and I wonder if I should go through the hassle and use
spawn_redirected to catch and return the output from there.
One of the main problems is that we have no spawn_redirected
implementation on win32 yet, so --external will fail there. On the other
hand I wonder how many people actually use --external nowadays, given
the fact that we haven't heard many complaints that the internal diff
algorithm produces wrong results compared to diff(1).
Another problem with --external is that its currently also only
available in diff, but not automate content_diff, for much of the same
reason that the diff command plainly prints out the created diff, so
there is this minor incompleteness between both commands.
So, is this a must-have feature or do you think this could be removed
(and simplify and fasten the code at the same time)?
Thomas.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?
Richard Levitte writes:
> In message <4d27b530.1080...@thomaskeller.biz> on Sat, 08 Jan 2011 01:52:00
> +0100, Thomas Keller said:
>
> me> I'm working on issue 102 and to make this work properly I want to
> me> create the diff output and return it instead of just printing it
> me> to stdout directly. Problem is that the external diff hook calls
> me> execute("diff", "-u", ...) and I wonder if I should go through the
> me> hassle and use spawn_redirected to catch and return the output
> me> from there.
>
> I'm not sure what you're about to do... it does sound like you want
> to create the whole diff in memory and output it when it's complete.
> In my opinion, that would be a bad idea (think huge diffs),
It can't be much bigger than twice the file size, and we routinely store
entire files in memory.
Hmm. depending on the diff format, I suppose it could be four or five
times the file size in an absolute worst case; still not really a
problem.
> and I'm not quite sure how that would fix the sorting order, which is
> the actual issue here. Maybe I misunderstand what you're thinking of
> doing...
+1.
What branch is this on?
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?
Thomas Keller writes:
> I'm working on issue 102 and to make this work properly I want to create
> the diff output and return it instead of just printing it to stdout
> directly. Problem is that the external diff hook calls execute("diff",
> "-u", ...) and I wonder if I should go through the hassle and use
> spawn_redirected to catch and return the output from there.
>
> One of the main problems is that we have no spawn_redirected
> implementation on win32 yet, so --external will fail there. On the other
> hand I wonder how many people actually use --external nowadays, given
> the fact that we haven't heard many complaints that the internal diff
> algorithm produces wrong results compared to diff(1).
>
> Another problem with --external is that its currently also only
> available in diff, but not automate content_diff, for much of the same
> reason that the diff command plainly prints out the created diff, so
> there is this minor incompleteness between both commands.
>
> So, is this a must-have feature or do you think this could be removed
> (and simplify and fasten the code at the same time)?
I don't use 'mtn diff --external'. When I want to run an external diff,
I just fetch the file text from mtn, then run diff.
So I think it could be removed (after 1.0?).
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll: Does anybody actually still use diff with --external?
In message <4d27b530.1080...@thomaskeller.biz> on Sat, 08 Jan 2011 01:52:00
+0100, Thomas Keller said:
me> I'm working on issue 102 and to make this work properly I want to
me> create the diff output and return it instead of just printing it
me> to stdout directly. Problem is that the external diff hook calls
me> execute("diff", "-u", ...) and I wonder if I should go through the
me> hassle and use spawn_redirected to catch and return the output
me> from there.
I'm not sure what you're about to do... it does sound like you want
to create the whole diff in memory and output it when it's complete.
In my opinion, that would be a bad idea (think huge diffs), and I'm
not quite sure how that would fix the sorting order, which is the
actual issue here. Maybe I misunderstand what you're thinking of
doing...
Cheers,
Richard
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Quick poll: Does anybody actually still use diff with --external?
I'm working on issue 102 and to make this work properly I want to create
the diff output and return it instead of just printing it to stdout
directly. Problem is that the external diff hook calls execute("diff",
"-u", ...) and I wonder if I should go through the hassle and use
spawn_redirected to catch and return the output from there.
One of the main problems is that we have no spawn_redirected
implementation on win32 yet, so --external will fail there. On the other
hand I wonder how many people actually use --external nowadays, given
the fact that we haven't heard many complaints that the internal diff
algorithm produces wrong results compared to diff(1).
Another problem with --external is that its currently also only
available in diff, but not automate content_diff, for much of the same
reason that the diff command plainly prints out the created diff, so
there is this minor incompleteness between both commands.
So, is this a must-have feature or do you think this could be removed
(and simplify and fasten the code at the same time)?
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Quick poll: monotone-users list?
On 14.07.2010 14:44, Ethan Blanton wrote:
> All of that said, as discussed on IRC, a procmail recipe also solves
> my annoyance.
If you have a Sieve-enabled mailhost or -client, you could use something
like
> if anyof (
> header :regex "Subject" "\[Monotone.*\]",
> header :regex "Subject" "\[bug \#\d+\]"
> )
> {
> discard;
> stop;
> }
And don't forget to
> require ["regex",...
at the top of the Sieve script.
Just for convenience.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll: monotone-users list?
Hey Thomas, On Wed, 14 Jul 2010, Thomas Keller wrote: So, would you like to see [+1] (or even subscribe to [+2]) monotone-users? Or is monotone-devel, monotone-announce and monotone-i18n enough [-1]? Personally, I can understand the convenience of an users list for some people that happen to not want the development discussions, but I for one don't see enough traffic to feel concerned about it. I would subscribe to it, if it were created, but I don't care if it is created. I do want to see the tickets, though, regardless, so as long as they are in some list, I'm happy. Aaron W. Hsu ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll: monotone-users list?
Am 14.07.2010 14:44, schrieb Ethan Blanton: > Thomas Keller spake unto us the following wisdom: Actually, this is a bit too much - no wisdom here :) >> I don't like to remove the ticket notifications from the devel list, >> because this basically hinders the awareness of new tickets - which we >> suffered from over the last couple of years. > > A -tickets or -bugs list has solved this handily for a number of > projects to which I belong. This might work for bigger communities, but I think not for ours. Only a few people would subscribe to -tickets and this would lead to the same problem: If something was reported on savannah and I (or somebody else) "accidentially" noticed it, I had to bug one of the other devs manually to create awareness of the problem and eventually fix it. > All of that said, as discussed on IRC, a procmail recipe also solves > my annoyance. I do think that unsubscribing is less effort than a > procmail recipe, and you're likely to get people taking that route > rather than digging through savanna chuff, Is there #savannah-haters anywhere? I somehow have the impression this channel would have many users... > but that feeling isn't a > useful argument, and it probably doesn't matter even if it is -- those > people just aren't that interested. The recent discussion about the changelog editing capabilities made me thought that a separate -users list could be useful in another area as well: to let interested parties know that new features arrived in mainline. Purely informational, of course, but with a few examples and maybe links to the daily builds which incorporate these changes. Maybe fewer people which are mainly "users" from our perspective have then the need to follow -devel at all...? Heavily depends on the number of users on -users of course - right now the amount of marketing I try to do for monotone already hits my upper bounds, and with no users reading / discussing these things it makes obviously no sense. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Quick poll: monotone-users list?
Thomas Keller spake unto us the following wisdom: > The discussion came up yesterday that some people are annoyed of the > amount of tickt / savannah spam on the development list. I proposed to > setup a dedicated "monotone-users" list which would not get these > messages and which could serve as entry point for user requests / > questions / problems and the like. I was the one who brought this up, and this does not solve my problem. I wish to follow monotone development and development issues, but I am uninterested in changes to ticket status. I explained this on IRC. If other people think a -users list is useful, great, of course. > I don't like to remove the ticket notifications from the devel list, > because this basically hinders the awareness of new tickets - which we > suffered from over the last couple of years. A -tickets or -bugs list has solved this handily for a number of projects to which I belong. > So, would you like to see [+1] (or even subscribe to [+2]) > monotone-users? Or is monotone-devel, monotone-announce and > monotone-i18n enough [-1]? -1*i. -devel + -announce + -i18n + -tickets would be superior. ;-) All of that said, as discussed on IRC, a procmail recipe also solves my annoyance. I do think that unsubscribing is less effort than a procmail recipe, and you're likely to get people taking that route rather than digging through savanna chuff, but that feeling isn't a useful argument, and it probably doesn't matter even if it is -- those people just aren't that interested. If ticket spam is staying on -devel under any given proposal, I consider the case closed as "Ethan is in the minority." Which is fine. :-) Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll: monotone-users list?
Am 14.07.2010 09:32, schrieb Thomas Keller: > > Hi! > > The discussion came up yesterday that some people are annoyed of the > amount of tickt / savannah spam on the development list. I proposed to > setup a dedicated "monotone-users" list which would not get these > messages and which could serve as entry point for user requests / > questions / problems and the like. I don't like to remove the ticket > notifications from the devel list, because this basically hinders the > awareness of new tickets - which we suffered from over the last couple > of years. > > So, would you like to see [+1] (or even subscribe to [+2]) > monotone-users? Or is monotone-devel, monotone-announce and > monotone-i18n enough [-1]? Here we go: http://lists.nongnu.org/mailman/listinfo/monotone-users Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Quick poll: monotone-users list?
On 07/14/2010 09:32 AM, Thomas Keller wrote: > So, would you like to see [+1] (or even subscribe to [+2]) > monotone-users? Or is monotone-devel, monotone-announce and > monotone-i18n enough [-1]? +2 Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Quick poll: monotone-users list?
Hi! The discussion came up yesterday that some people are annoyed of the amount of tickt / savannah spam on the development list. I proposed to setup a dedicated "monotone-users" list which would not get these messages and which could serve as entry point for user requests / questions / problems and the like. I don't like to remove the ticket notifications from the devel list, because this basically hinders the awareness of new tickets - which we suffered from over the last couple of years. So, would you like to see [+1] (or even subscribe to [+2]) monotone-users? Or is monotone-devel, monotone-announce and monotone-i18n enough [-1]? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Quick poll
In message <4c1209d2.6070...@thomaskeller.biz> on Fri, 11 Jun 2010 12:02:58 +0200, Thomas Keller said: me> 1) I will release 0.48 this weekend (probably Sunday) when the remaining me> openBSD issues have been sorted out. The translation team therefor has a me> one or two more days to improve the i18n side, but its not that crucial me> anymore to bring them up to 100% excellence since we won't hit 0.99 next. Following many years of experience from the FSF folks, I'd suggest 0.90. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll
Am 11.06.2010 12:56, schrieb Stephen Leake: > Thomas Keller writes: >> [...] Is everybody ok with that? > > Excellent plan. Cool! > We might as well start the 2.0 list now; anything that doesn't make 1.0 > is a candidate for 2.0. > > I just added 'update conflict handling' and 'overwritable, negatable > options'. I was just in the process and reworked the complete page to a more dense layout. Could I ask you and link the explanations for either idea to a wiki page or a mailing list post? And please only set branch names which actually already exists, otherwise people might get confused. For now I've added the options task for 1.0 and the update conflict handling in untargeted - we might as well include the latter in 1.1, 1.2 or so if its ready and since the work hasn't even be started yet, I refuse to put it for a particular milestone. The things for 1.0 / 2.0 which haven't been started are just already there because they're blockers, i.e. we absolutely want them to pop up in this particular release... if there are more such items, we might move them up from "Not targeted" or add them as new, but I advise everyone here to be very, very conservative, especially if you don't plan to do the particular work yourself :) >> PS: Wish me luck tomorrow - I'll be on the LinuxTag in Berlin and try to >> persuade a hosting company (Thomas Krenn AG) to sponsor [1] us some >> hardware :) > > Go for it! Thanks, Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Quick poll
Thomas Keller writes: > Hi everyone! > > I'm listening to you and the release concerns, which (again) popped up > recently. And since I don't want to behave like a self-opinionated > bastard which just pushes things to the very end while people are > uncomfortable with the situation, here is the new plan: > > > 1) I will release 0.48 this weekend (probably Sunday) when the remaining > openBSD issues have been sorted out. The translation team therefor has a > one or two more days to improve the i18n side, but its not that crucial > anymore to bring them up to 100% excellence since we won't hit 0.99 next. > > 2) After 0.48 is out, the next dev version will be 0.99dev. > > 3) Tim and Stephe proposed to set up a list of things we really want to > get done and which are also doable in a reasonable time frame before > 0.99 / 1.0 hits the streets. I'd like to target this fall for 0.99 and > we should really try to get things done until then. > > 4) I'll tweak the old RoadMap [0] wiki page and bring it up-to-date. > People are invited to add more things which they want to see in 1.0 and > we're collaboratively voting on them and moving them into the > appropriate position afterwards. To avoid new features added constantly > afterwards, feature proposals for 1.0 are only open until Sunday. > > > Is everybody ok with that? Excellent plan. We might as well start the 2.0 list now; anything that doesn't make 1.0 is a candidate for 2.0. I just added 'update conflict handling' and 'overwritable, negatable options'. > PS: Wish me luck tomorrow - I'll be on the LinuxTag in Berlin and try to > persuade a hosting company (Thomas Krenn AG) to sponsor [1] us some > hardware :) Go for it! -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Quick poll
Hi everyone! I'm listening to you and the release concerns, which (again) popped up recently. And since I don't want to behave like a self-opinionated bastard which just pushes things to the very end while people are uncomfortable with the situation, here is the new plan: 1) I will release 0.48 this weekend (probably Sunday) when the remaining openBSD issues have been sorted out. The translation team therefor has a one or two more days to improve the i18n side, but its not that crucial anymore to bring them up to 100% excellence since we won't hit 0.99 next. 2) After 0.48 is out, the next dev version will be 0.99dev. 3) Tim and Stephe proposed to set up a list of things we really want to get done and which are also doable in a reasonable time frame before 0.99 / 1.0 hits the streets. I'd like to target this fall for 0.99 and we should really try to get things done until then. 4) I'll tweak the old RoadMap [0] wiki page and bring it up-to-date. People are invited to add more things which they want to see in 1.0 and we're collaboratively voting on them and moving them into the appropriate position afterwards. To avoid new features added constantly afterwards, feature proposals for 1.0 are only open until Sunday. Is everybody ok with that? Thomas. PS: Wish me luck tomorrow - I'll be on the LinuxTag in Berlin and try to persuade a hosting company (Thomas Krenn AG) to sponsor [1] us some hardware :) [0] http://monotone.ca/wiki/RoadMap/ [1] http://www.thomas-krenn.com/de/unternehmen/news/action.view/entity.detail/detail_key.280.html (in German) -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] quick poll
(Pardon if this was already concluded in-channel or elsewhere, I have been on vacation.) Nathaniel Smith spake unto us the following wisdom: > Should it be possible to commit with an empty changelog, if someone > really wants to? Like, if they actually pass '-m ""' on the command > line or whatever. Most definitely. Remember that version control systems are not used only to store source code with logical changes which can be summarized in comments. In my experience version control systems are used with some frequency for automated tasks for which meaningful commit messages would be difficult or impossible to generate. As you mentioned, -m "foo" could be used in these cases; however, I feel that a primary purpose of tools is to shut up and get out of my way. I feel the same way about a default hook forbidding empty log messages. If I want to forbid empty log messages, I'll write a hook to enforce that policy... (The bottom line is that an automated tool is never* going to be able to enforce "good" commit messages ... it's amazing how much work people will put into not doing their work right. Only competent commit message authors can ensure truly good commit messages.) Ethan * AI notwithstanding. -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 pgptZPF5hBd82.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] quick poll
On 8/12/05, Matthew A. Nicholson <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > IMHO this should be a lua hook. Put a regexp template on the message using > > the hook. > > > > If you want to force a message, you probably want to force the format too > > > > Joel > > I would be ok with a hook, but not an option. A hook to validate a > comment is actually not a bad idea. The default hook could reject empty > comments. Personally I see no reason for empty comments, but a hook for > validating comments does look like a good idea and could be used for the > empty comment thing too. It (the hook) indeed is a very good idea. I know many projects could use it to ensure that commit messages follow predefined guidelines (e.g., bug numers are given in a specific format, code reviewers are mentioned and their names are correct, etc.). Having it default to not allowing empty logs seems good enough. -- Julio M. Merino Vidal <[EMAIL PROTECTED]> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] quick poll
[EMAIL PROTECTED] wrote: IMHO this should be a lua hook. Put a regexp template on the message using the hook. If you want to force a message, you probably want to force the format too Joel I would be ok with a hook, but not an option. A hook to validate a comment is actually not a bad idea. The default hook could reject empty comments. Personally I see no reason for empty comments, but a hook for validating comments does look like a good idea and could be used for the empty comment thing too. -- Matthew A. Nicholson Digium ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] quick poll
On Fri, Aug 12, 2005 at 06:48:29AM -0400 Richard Li wrote: > Date: Fri, Aug 12, 2005 at 06:48:29AM -0400 > From: Richard Li <[EMAIL PROTECTED]> > To: To [EMAIL PROTECTED] > Subject: Re: [Monotone-devel] quick poll Hi, > +1. I think lua is a good place to put policy (sort of a vague heuristic). Yes, I think that should be a LUA hook. We use a project-monotonerc where we could insert the same RegExp we use with CVS. Leif ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] quick poll
+1. I think lua is a good place to put policy (sort of a vague heuristic). I think yet another option is not a good idea. You want to avoid option explosion for usability and backwards compatibility, especially for boundary cases. [EMAIL PROTECTED] wrote: IMHO this should be a lua hook. Put a regexp template on the message using the hook. If you want to force a message, you probably want to force the format too Joel Should it be possible to commit with an empty changelog, if someone really wants to? Like, if they actually pass '-m ""' on the command line or whatever. One part of me says "of course everyone should be made to do commit messages", and then another part says "dude, if someone want sto go out and say 'commit -m ""', all you're going to do is annoy them and get them to say 'commit -m "foo"', like _that_ helps...". Robert Collins suggests adding yet another option, like --empty-log. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] quick poll
IMHO this should be a lua hook. Put a regexp template on the message using the hook. If you want to force a message, you probably want to force the format too Joel > Should it be possible to commit with an empty changelog, if someone > really wants to? Like, if they actually pass '-m ""' on the command > line or whatever. > > One part of me says "of course everyone should be made to do commit > messages", and then another part says "dude, if someone want sto go > out and say 'commit -m ""', all you're going to do is annoy them and > get them to say 'commit -m "foo"', like _that_ helps...". > > Robert Collins suggests adding yet another option, like --empty-log. > > -- Nathaniel > > -- > So let us espouse a less contested notion of truth and falsehood, even > if it is philosophically debatable (if we listen to philosophers, we > must debate everything, and there would be no end to the discussion). > -- Serendipities, Umberto Eco > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel > > ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] quick poll
Nathaniel Smith wrote: Should it be possible to commit with an empty changelog, if someone really wants to? Like, if they actually pass '-m ""' on the command line or whatever. -m "" or so should be possible. If things actually go to an editor (no -m), an empty log should be rejected. Robert Collins suggests adding yet another option, like --empty-log. Overkill, imho. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] quick poll
On Fri, Aug 12, 2005 at 12:41:24AM -0700, Nathaniel Smith wrote: > Should it be possible to commit with an empty changelog, if someone > really wants to? Like, if they actually pass '-m ""' on the command > line or whatever. > > One part of me says "of course everyone should be made to do commit > messages", and then another part says "dude, if someone want sto go > out and say 'commit -m ""', all you're going to do is annoy them and > get them to say 'commit -m "foo"', like _that_ helps...". > > Robert Collins suggests adding yet another option, like --empty-log. I'll put in a vote for Robert's suggestion. You should be able to do it, but should _definitely_ have to work for it. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Ceci n'est pas une pipe: | --- signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] quick poll
Should it be possible to commit with an empty changelog, if someone really wants to? Like, if they actually pass '-m ""' on the command line or whatever. One part of me says "of course everyone should be made to do commit messages", and then another part says "dude, if someone want sto go out and say 'commit -m ""', all you're going to do is annoy them and get them to say 'commit -m "foo"', like _that_ helps...". Robert Collins suggests adding yet another option, like --empty-log. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
