Timothy Brownawell wrote:
On Mon, 2009-01-26 at 22:29 -0600, Matthew Nicholson wrote:
Greetings,
My rename --guess work from the mini summit is ready for testing and
review. It can be found in the net.venge.monotone.rename-guess branch.
The rename --guess command attempts to match files in
all from source.
I think this is a great idea. I haven't looked at the library-build
branch yet, but off the top of my head we could basically just use the
build system of each library and make them install into a special
staging dir, then build monotone against that statically link
from the commit message. As long as these changes
don't change things for users who are used to just editing the commit
message, I don't have a problem with these new options.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Markus Wanner wrote:
Hi,
Matthew Nicholson wrote:
From a packager's standpoint, using the system headers makes security
bugs more explicit. If the packager's build system knows that monotone
has a build time dependency on a particular library (even if it is
header only) and a secur
will
detect renames of identical files and renames of directories composed of
identical files. Future improvements may include, renames of files and
directories with partial content changes.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel
message-log = "_MTN/log".
Any objections?
Sounds good to me too.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
eader only) and a security bug is found in that library, then the
packager knows it needs to recompile that library. If the library is
bundled in monotone, that information is lost.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
libraries would be more prevalent. And instead of relying on SSH for
authentication, we could add the option of using PAM for authentication
which is what SSH uses anyway.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Mono
matthew_i as well when I am at work).
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
time.
I have no problem with using skype in addition to IRC.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
. Unfortunately I will not be able to participate until the evening
of the 17th, so you will have to start with out me.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo
to monotone
development (which we may already have). This guide would contain
descriptions of the macros we use and the principles that monotone is
developed by.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monot
Lapo Luchini wrote:
Matthew A. Nicholson wrote:
No one strongly objected to the January 18 and 19, 2009 time frame
Wasn't it 17-18? January 19 is a monday =)
Yes that is correct, my mistake.
--
Matthew Nicholson
matt-land.com
___
Mon
on by January 12th,
and then flesh those out for a week until the 17th so that we have a
solid agenda for our virtual summit.
[1] http://mtn-wiki.1erlei.de/wiki/MtnSummit/2009
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
lendar and
Just Be There ;)
Those dates work for me.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
se to thanksgiving (US) or christmas?
So what about these dates? Or others?
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
%20Functions/NT%20Objects/Process/NtCreateProcess.html
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Stephen Leake wrote:
Matthew Nicholson <[EMAIL PROTECTED]> writes:
Zack Weinberg wrote:
On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote:
* lua: pretty similar to sqlite, except the source inclusion variant is
a bit more complicated. I'm all for dy
asio in my astxx library. I have not had any problems with
it, seems well designed. Also there is a non-boost version of it for
the anti boost crowd (I happen to be pro-boost).
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Mono
and longjmp for error handling when compiled as C and
exceptions when compiled as C++. If we don't require stack unwinding on
error (I have not looked at the code), then dynamic linking is fine, but
I think this is a candidate for bundling.
ld also do this in a separate branch.
After you commit the hot fix (Issue_B), you can continue working on
Feature_A as you were, commit and then merge later (mtn commit, mtn
merge, see monotone branches can have two heads), or you can merge that
change into your Feature_A workspace (mtn up) an
centralised
control of branch naming (policy branches) - it is all just local.
I like the idea of local branch namespaces. How do they implement it?
Just use like the sha1 hash of various things as the true branch name
and then map that to a texual name locally?
--
Matthew Nicholson
matt-land.com
te. Not
sure how that would affect performance or if we are willing to link with
boost date_time.
P.S. I noticed this issue too, and it is kind of annoying. It makes
using the dates in monotone some what difficult.
--
Matthew Nicholson
matt-land.com
___
ld use a restriction to the current dir (mtn add --unknown .). I
remember some discussion about mtn ls unknown and such always acting
from the root directory a while back.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-d
es is reverted/disapproved, those nodes should come back,
right now they don't (they are replaced with new nodes with the same
content).
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
William Uther wrote:
On 07/05/2008, at 1:21 PM, Matthew Nicholson wrote:
William Uther wrote:
This third option would avoid the drops entirely. It has the problem
that I don't know how to reverse it. i.e. if you merge two node-ids
then you could never tease them apart again. Hrm.
r to what I was thinking when the "atomic drop two
add one" idea was first presented. This is basically a combination of
your options i and iii, although with pure option 3 you don't need the
graveyard.
--
Matthew Nicholson
matt-land.com
Thomas Keller wrote:
Matthew Nicholson schrieb:
So,
Should mtn checkout be modified to work like mtn clone? I know it has
been mtn co -b ... for ages, but should it be changed to mtn checkout
branch.name dir? That would make it more like mtn clone and also more
like svn checkout. On
), might try to check out the '../new_ws' branch and fail.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
rly enough.
I would have to say, I describe my feelings about nuskool as "worried"
and "curious" rather than "anticipatory", but then again, I don't know
much about it.
--
Matthew Nicholson
matt-land.com
___
Thomas Keller wrote:
Matthew Nicholson schrieb:
Dennis Schridde wrote:
(3)
clone takes a -b argument to specify the branch, while pull wants it
as a normal argument.
The first time I used mtn clone, I found this a little strange too.
Every command in monotone except the netsync commands
transition mtn pull/push/sync to use -b
instead of a branch pattern. Although this would also raise the issue
of passing a branch pattern to -b which is not consistent with how -b
works in the rest of monotone.
P.S. Dennis, it looks like the proper authorities are ignoring you :).
--
Matthew
ohibit use of '-' and
'/') it seems like it's a good time for rethinking branch naming policies.
This would break some existing databases (mine being one) and would
either need to be handled by supporting branch renaming (magical policy
branches?) or by renaming the b
me
mtn sy mtn://monotone.ca?nvm*&!nvm.experiment*
Personally I think that looks horrible and confusing vs the --include
--exclude syntax. The variant that has ?include=pattern&exclude=pattern
is slightly more readable, but I still prefer the command line switches.
Brian May wrote:
"Matthew" == Matthew Nicholson <[EMAIL PROTECTED]> writes:
Matthew> P.S. I am not sure if anyone other then me is using vim
Matthew> to merge, it seems like a lot of you use real merge tools
Matthew> (e.g., kdiff3, xxdiff, ...).
vi
design and functionality and maintained upstream
(and will be a part of the next major boost release).
[0] http://asio.sourceforge.net/
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailma
f3, xxdiff, ...).
--
Matthew Nicholson
matt-land.com
mergers.vim = {
cmd = function (tbl)
function execute_diff3(mine, yours, out)
local diff3_args = {
"diff3",
"--merge",
"--easy-only",
}
t
cted monotone since 0.29 now. Could you
> lend some time to help me troubleshoot?
>
> Cheers,
> Shaun
>
> http://bugs.debian.org/384565
I check that bug out. I thought you had it handled.
--
Matthew Nicholson
matt-land.com
___
Monot
will be in the next version of boost maybe.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
might be just me, but it makes it much
harder for me to reason about the probosed solutions.
It's not just you :).
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listin
e-permissions) should simply be
moved down to the directory examples/ and then debian/examples/ should
be removed?
(Matthew Nicholson, since you created the nvm.debian branch, what's
your take on this?)
Ok, on nvm.debian, the debian/monotone-server.examples is where that
stuff should go
Nathaniel Smith wrote:
On Thu, Aug 24, 2006 at 08:55:03PM -0500, Matthew Nicholson wrote:
Nathaniel Smith wrote:
On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote:
Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
on mtn log) fix pidfile cleanup? The
Nathaniel Smith wrote:
On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote:
Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
on mtn log) fix pidfile cleanup? The test seems to still be an xfail.
Umm, no... forgot about that :-).
It should be
Greetings,
Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
on mtn log) fix pidfile cleanup? The test seems to still be an xfail.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
s
still the same, CVS tries to do the previous merge a second time. I
take it Monotone has no such problems?
Correct, monotone has no such problems. If you try to pluck the same
thing twice it will try to do the previous merge again, but if you
propagate or explicit_merge it know how to handle d
my website...
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[EMAIL PROTECTED] wrote:
no, pluck is for basic cherrypicking - applying patches without their
dependencies (ancestry)
explicit_merge seems to be what you want (plus an improved propagate UI that
allows selecting between heads)
Ok, i'll try explicit_merge. Thanks.
--
Matthew Nich
Matthew Nicholson wrote:
Greetings,
It appears you can only propagate from the head of one single-headed
branch to the head of another single-headed branch. Is this an
artificial restriction that monotone places or are there logical reasons
other similar operations are not possible?
I am
from a tagged revision to the head of my
current branch (mtn prop t:monotone-0.28 net.venge.monotone.debian).
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone
49 matches
Mail list logo
