Re: [Monotone-devel] time for a release?

2010-05-17 Thread Derek Scherger 
On Mon, May 17, 2010 at 2:33 AM, Thomas Keller  wrote:

> \2) I'd like to get my nvm.experiment.database-management branch ready
> and merged in as well, so the change I did earlier to mtn setup (which
> now creates a database if none is given) is changed to "create a
> database in the default location or use the default database there". The
> code compiles already and partially works, but I had to do a couple of
> non-related changes to make database objects easier constructable and
> other things, which make mtn currently crash badly. I'll commit my
> current state tonight, so others have time to look at it. Maybe I'm on a
> wrong path there.
>

I had a quick look over your changes and they seem fairly reasonable. A few
minor things:

We seem to be using lots of redundant std:: prefixes in various .cc files
(not just in your changes) where we also have using std::foo declarations to
avoid needing the std:: prefixes throughout the implementation. Do people
have a general preference for explicit prefixes? Personally I much prefer a
using declaration and less cluttered sources, iterators are already bad
enough, sprinkling them with std:: makes them worse! ;)

Some of your changelog comments use very long lines and are somewhat hard to
read without a tool that does automatic, but careful, wrapping (viewing
these in emacs diff-mode is not particularly pleasant). Can you try and wrap
these at some reasonable length please?

Based on all the shenanigans with ".mtn" extensions it seems like maybe the
path handling code could use a more formal concept of extension.

A shared_ptr for the lazy_rng would probably be better than a raw pointer.

We should probably have a ":memory:" constant somewhere, rather than
multiple string instances.

I don't think you want to set the foo_given flags when reading options from
the options file do you? Isn't the point of these to know whether the user
specified such an option on the command line?

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: new restrictions branch for including required parents

2010-05-17 Thread Derek Scherger 
On Mon, May 17, 2010 at 2:26 AM, Thomas Keller  wrote:

> Ok, as long as you have documented that for the revert command,
> everything should be fine. A short note in NEWS shouldn't hurt as well.
>

Done and ready to merge. Any objections?

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] time for a release?

2010-05-17 Thread Thomas Keller 
Am 17.05.2010 10:33, schrieb Thomas Keller:
> Am 17.05.2010 08:32, schrieb Stephen Leake:
>> Timothy has fixed the branch_leaves cache bug, and merged the change-log
>> editor improvements and added --update/--no-update to main. Several
>> other bug fixes have been done.
>>
>> And all tests are currently passing (at least on Debian).
>>
>> So I think it's time for a release?
> 
> Yes, it is time, but I'd like to wait a little longer, for a couple of
> reasons:
> 
> 1) I want to have all finished branches from our bugfest merged in first
> (I'm not sure, but I think at least Richard's is missing)
> 
> 2) I'd like to get my nvm.experiment.database-management branch ready
> and merged in as well, so the change I did earlier to mtn setup (which
> now creates a database if none is given) is changed to "create a
> database in the default location or use the default database there". The
> code compiles already and partially works, but I had to do a couple of
> non-related changes to make database objects easier constructable and
> other things, which make mtn currently crash badly. I'll commit my
> current state tonight, so others have time to look at it. Maybe I'm on a
> wrong path there.
> 
> 3) I want to have a time window between the last feature merge and the
> release of at least one or two weeks, for two reasons: have more people
> test the changes and give the translators a chance to pick up the new
> strings.

On a related note, apparently some of the build bots fail - at least the
Fedora one

http://monotone.thomaskeller.biz/autobuild/index.php?log=Fedora_12/i586/monotone-fedora

and the openBSD one

http://monotone.ca/buildbot/x86-openbsd/builds/803/step-test/0

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

[Monotone-devel] monotone package for Homebrew (Mac OS X)

2010-05-17 Thread Thomas Keller 

Hi!

Apparently there is a new kid on the block when it comes to package
managers / software installers on Mac OS X - dubbed Homebrew
(http://mxcl.github.com/homebrew/) - and somebody was already so nice
and created a recipe for monotone there:

http://github.com/mxcl/homebrew/blob/master/Library/Formula/monotone.rb

So if you dislike MacPorts or Fink for some reason, you might want to
look into Homebrew instead.

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

[Monotone-devel] [bug #8033] only warn about unknown certs when it causes trust failure

2010-05-17 Thread Timothy Brownawell 

Update of bug #8033 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Please review nvm.experiment.lua-output-redirection

2010-05-17 Thread Thomas Keller 
Am 17.05.2010 13:59, schrieb Stephen Leake:
> Thomas Keller  writes:
> 
>> Am 11.05.10 02:02, schrieb Thomas Keller:
>>>
>>> Hi!
>>>
>>> I've committed my recent lua-related changes to the above mentioned
>>> branch. Please review that again, especially the documentation changes
>>> since I'm still not a native speaker...
>>
>> I received no comments here, so that means my documentation changes are
>> ok then...?
> 
> Sorry, I meant to get to this on the weekend.
> 
> I like the renaming of "Hook reference" to "Lua reference".
> 
> I did a bit of cleaning up in the intro to hooks, and the new section
> "Implementation Differences".

Thanks for the changes - the branch has just been merged to nvm.

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] time for a release?

2010-05-17 Thread Stephen Leake 
Thomas Keller  writes:

> Am 17.05.2010 08:32, schrieb Stephen Leake:
>> Timothy has fixed the branch_leaves cache bug, and merged the change-log
>> editor improvements and added --update/--no-update to main. Several
>> other bug fixes have been done.
>> 
>> And all tests are currently passing (at least on Debian).
>> 
>> So I think it's time for a release?
>
> Yes, it is time, but I'd like to wait a little longer, for a couple of
> reasons:
>
> 1) I want to have all finished branches from our bugfest merged in first
> (I'm not sure, but I think at least Richard's is missing)

Ok.

> 2) I'd like to get my nvm.experiment.database-management branch ready
> and merged in as well, so the change I did earlier to mtn setup (which
> now creates a database if none is given) is changed to "create a
> database in the default location or use the default database there". 

Yes, that would be good.

> The code compiles already and partially works, but I had to do a
> couple of non-related changes to make database objects easier
> constructable and other things, which make mtn currently crash badly.
> I'll commit my current state tonight, so others have time to look at
> it. Maybe I'm on a wrong path there.

I'll try to look at it.

> 3) I want to have a time window between the last feature merge and the
> release of at least one or two weeks, for two reasons: have more people
> test the changes and give the translators a chance to pick up the new
> strings.
>
> So from the current point of view a release should be realistic around
> June 1st or shortly after.

Sounds good.

-- 
-- Stephe

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] bugfest analysis - final points

2010-05-17 Thread Thomas Keller 
Am 17.05.2010 14:08, schrieb Stephen Leake:
> Thomas Keller  writes:
>> Am 16.05.10 11:19, schrieb Stephen Leake:
>>> For net.venge.monotone.bugfest-2010.13604-stephen_leake, I've removed
>>> the --recursive option from 'undrop'. So I think this is ready to merge.
>>>
>>> net.venge.monotone.restrictions.implicit-includes will change what
>>> 'revert' does with some restrictions; since 'undrop' shares core code
>>> with 'revert', there's no need to wait for that branch.
>>
>> I haven't followed your conversation with Derek further - just to get a
>> ok from you both: undrop is still needed even after the new restriction
>> code landed, right?
> 
> Yes, because the sequence:
> 
> drop foo
> revert foo
> 
> clobbers a locally modified 'foo'; 'drop' doesn't actually delete it,
> but 'revert' overwrites it.
> 
> The other alternative is:
> 
> drop foo
> add foo
> 
> This keeps the modified file, but also changes the node id, losing history.
> 
> 'undrop' solves both of these problems.
> 
> One alternative we did not really investigate would be:
> 
> drop foo
> revert --move-conflicting-paths foo
> cp _MTN/resolutions/foo .
> 
> That would be equivalent to 'undrop'. I think 'undrop' is friendlier.

Ok, cool, so if documentation and NEWS is up to date, go and merge it!

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] bugfest analysis - final points

2010-05-17 Thread Stephen Leake 
Thomas Keller  writes:

> Am 16.05.10 11:19, schrieb Stephen Leake:
>> Thomas Keller  writes:
>> 
>>> For the others: If you think your branch is ready for the final merge,
>>> give me a note if you want to get it reviewed another time, otherwise
>>> just merge it.
>> 
>> For net.venge.monotone.bugfest-2010.13604-stephen_leake, I've removed
>> the --recursive option from 'undrop'. So I think this is ready to merge.
>> 
>> net.venge.monotone.restrictions.implicit-includes will change what
>> 'revert' does with some restrictions; since 'undrop' shares core code
>> with 'revert', there's no need to wait for that branch.
>
> I haven't followed your conversation with Derek further - just to get a
> ok from you both: undrop is still needed even after the new restriction
> code landed, right?

Yes, because the sequence:

drop foo
revert foo

clobbers a locally modified 'foo'; 'drop' doesn't actually delete it,
but 'revert' overwrites it.

The other alternative is:

drop foo
add foo

This keeps the modified file, but also changes the node id, losing history.

'undrop' solves both of these problems.

One alternative we did not really investigate would be:

drop foo
revert --move-conflicting-paths foo
cp _MTN/resolutions/foo .

That would be equivalent to 'undrop'. I think 'undrop' is friendlier.

-- 
-- Stephe

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Please review nvm.experiment.lua-output-redirection

2010-05-17 Thread Stephen Leake 
Thomas Keller  writes:

> Am 11.05.10 02:02, schrieb Thomas Keller:
>> 
>> Hi!
>> 
>> I've committed my recent lua-related changes to the above mentioned
>> branch. Please review that again, especially the documentation changes
>> since I'm still not a native speaker...
>
> I received no comments here, so that means my documentation changes are
> ok then...?

Sorry, I meant to get to this on the weekend.

I like the renaming of "Hook reference" to "Lua reference".

I did a bit of cleaning up in the intro to hooks, and the new section
"Implementation Differences".

-- 
-- Stephe

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] time for a release?

2010-05-17 Thread Thomas Keller 
Am 17.05.2010 08:32, schrieb Stephen Leake:
> Timothy has fixed the branch_leaves cache bug, and merged the change-log
> editor improvements and added --update/--no-update to main. Several
> other bug fixes have been done.
> 
> And all tests are currently passing (at least on Debian).
> 
> So I think it's time for a release?

Yes, it is time, but I'd like to wait a little longer, for a couple of
reasons:

1) I want to have all finished branches from our bugfest merged in first
(I'm not sure, but I think at least Richard's is missing)

2) I'd like to get my nvm.experiment.database-management branch ready
and merged in as well, so the change I did earlier to mtn setup (which
now creates a database if none is given) is changed to "create a
database in the default location or use the default database there". The
code compiles already and partially works, but I had to do a couple of
non-related changes to make database objects easier constructable and
other things, which make mtn currently crash badly. I'll commit my
current state tonight, so others have time to look at it. Maybe I'm on a
wrong path there.

3) I want to have a time window between the last feature merge and the
release of at least one or two weeks, for two reasons: have more people
test the changes and give the translators a chance to pick up the new
strings.

So from the current point of view a release should be realistic around
June 1st or shortly after.

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] Re: new restrictions branch for including required parents

2010-05-17 Thread Thomas Keller 
Am 17.05.2010 00:39, schrieb Derek Scherger:
> On Sat, May 15, 2010 at 11:41 AM, Derek Scherger wrote:
> 
>> I've started a new branch net.venge.monotone.restrictions.implicit-includes
>> that changes the restrictions code to always include the parents of
>> explicitly included nodes.
>>
>> This turned out to be a relatively simple change and I've updated the
>> restriction unit-tests so that they are all passing. It's now a matter of
>> updating the lua tests and dealing with the fallout from that. After an
>> initial look over things it doesn't look like it should be too difficult to
>> do. Then it's just a matter of agreeing that the new semantics are an
>> improvement over the current semantics.
>>
> 
> This is now finished and ready for review. 

Very cool, I'll look over it tonight!

> The one case where implicit
> includes don't seem to make sense is for revert, where you might want to
> revert a file but not a rename of the directory that contains it. The
> restriction that revert uses doesn't apply the new implicit include rules
> but all other cases do. 

Ok, as long as you have documented that for the revert command,
everything should be fine. A short note in NEWS shouldn't hurt as well.

> I've assigned a few more bugs to myself related to
> this, all of which can probably be closed once this is merged. There were a
> few xfailed test cases that are now passing as well.

Cool, thanks for your work!

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