Am 21.10.2010 11:57, schrieb Stephen Leake:
> Emacs Gnus (which I use to read news and mail) does incorporate an RSS
> reader. However, I can't figure out what URL to give it;
> http://www.monotone.ca/ doesn't work, and I don't see anything on that
> page to indicate what the RSS URL might be.
>
>
Am 05.10.2010 12:28, schrieb Markus Wanner:
> What's the use case for getting file size information exclusively? I
> haven't ever needed just the size, but not the real data.
"Directory listings", eg. in repository browsers.
Or to use it as a means to determine if the full file should be loaded
or
Am 28.09.2010 15:01, schrieb Thomas Keller:
> Now if you know how one can easily process incoming mail (maildir / mbox
> / whatever style), we could probably set something up like this.
Add to /etc/aliases (or /etc/mail/aliases or whatever):
snip
issues: |/usr/bin/php /path/to/your/script
Am 16.09.2010 21:37, schrieb Stephen Leake:
>> Then add your public key(s) to the IDF account
>
> I don't see how to do this on the web page.
>
Click "Welcome, " in the top left.
Then "Update your account".
Then paste your key in "Add a public key"
Patrick
Am 10.08.2010 16:31, schrieb Gour D.:
> Any other means to quickly send some revisions via e.g. email, ala
> 'darcs send' ?
darcs patches are (somewhat) independent from each other. monotone
revisions aren't. Given that you can't know what other revisions the
other side already has, this is less si
Am 04.08.2010 16:22, schrieb Thomas Keller:
> How should it do that? I can only push keys from one database to
> another, but I want to put, i.e. store keys directly, similar to what
> `mtn read` provides. Use case: Admin enters the ascii-amored version of
> a public key in a web form and hits "add
Am 04.08.2010 09:51, schrieb Stephen Leake:
> From the bug discussion https://savannah.nongnu.org/bugs/?30345, it
> appears that the minimum necessary is already there, via 'mtn
> automate read_packets', and/or 'mtn sync --key-to-push'.
>
> So what is the indefero use case, and what is still miss
Am 17.07.2010 09:40, schrieb CooSoft Support:
> I'm not currently using 0.48 and from what I hear nor will I. I to want
> comments to go in unmolested and not have white space stripped out. For
> me that is a must.
I didn't look at the code, but that should only be empty lines before or
after the c
Am 03.07.2010 21:07, schrieb Stephen Leake:
> As I pointed out in my other post, line endings simply don't matter to
> most open source text processing tools.
Some of them use native line endings for new files. But I suppose that
can probably be changed, too.
I'm not sure how useful "we don't suppo
Am 03.07.2010 19:12, schrieb Richard Levitte:
> Good, this was discussed years ago, but the discussion drifted off
> into nothingness. A rehash could maybe take us closer to something
> workable.
>
> The usual problem is there, how to make certain we don't do
> conversions with files that should
Am 27.06.2010 08:12, schrieb Gour:
> Fortunately, I found out about git-export using fast-import mechanism,
> but I wonder if there is any plan for git-import to make it easier to
> convert from {darcs,git,hg} which support by fast-import/export
> mechanism?
I used to work on mtn-fast-import, which
Am Freitag, den 04.06.2010, 11:15 +0200 schrieb Ludovic Brenta:
> > It allows things like for example
> > mtn diff -r 'lca(h:*extended-selectors;h:net.venge.monotone)' -r
> > h:*extended-selectors
> I would prefer another character; the pipe needs quoting in most
> shells. Maybe ^?
^ is ancie
Am 01.06.2010 15:47, schrieb Jack Lloyd:
> How do I tell monotone to _not_ use a key for this operation?
-k '' should work
Patrick
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Am 22.12.2009 22:02, schrieb Markus Wanner:
> ..or modify cvs2git (which is based on cvs2svn) to export to something
> monotone can parse, instead of git-fast-import format.
>
> ..or write a git2mtn that can parse git-fast-import format.
I had a git-fast-import parser that emitted monotone packets
Am Dienstag, den 01.09.2009, 00:24 +0200 schrieb Thomas Keller:
> While push gained some speed, pull did not and even took a little longer
> here and there. I have to note here that all three processes of course
> used the same hardware, so there could be a speed penalty because of
> this, but sinc
Am 25.07.2009 10:46, schrieb Nathaniel Smith:
Yeah, that'd probably work -- loop over the cset, convert the paths
into node_id's, then just loop over those. The trick is making sure
you look up all the correct paths in the correct rosters so you never
miss any modified nodes -- this will take som
Am 25.07.2009 04:07, schrieb Stephen Leake:
Patrick Georgi writes:
The current code takes two rosters, compares them, and registers the
differences. The problem is that this approach scales by roster size
(which is directly dependent on the tree size). The problem is, that I'm
working
Hi,
I'm currently trying to optimize the roster deltification code (as used
by pull, put_revision, probably commit and others).
The current code takes two rosters, compares them, and registers the
differences. The problem is that this approach scales by roster size
(which is directly dependent on
CooSoft Support schrieb:
There may also be issues (probably not with mtn though) with the libc
runtime as it uses dynamic loading of certain plugin libraries for
authentication and hostname resolution (have seen this with some
systems).
The -Wl,Bstatic -Wl,Bdynamic switches are useful around
Am 21.05.2009 22:38, schrieb Stephen Leake:
How do you accomplish this? The monotone Makefile builds a dynamically
linked executable.
Simply by building the libraries with --disable-shared, and (in case of
libidn which doesn't care about user wishes) moving the dll (and .dll.a)
aside. The build
Am 20.05.2009 17:31, schrieb Stephen Leake:
I guess I should have looked ahead in the email traffic :).
There are instructions for building the win32 installer in
monotone/win32/README. It packages mtn.exe and the required dlls.
The installer currently on the monotone website contains a mtn.exe
Am 20.05.2009 17:20, schrieb Stephen Leake:
Do you want to take over publishing Win32 in the future?
Now that I have the toolchain up and running, I sure can do this.
Patrick
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.no
Am 18.05.2009 21:32, schrieb "Marcin W. Dąbrowski":
Mmm... Not so easy, unfortunately. The binary is not the setup,
but unstripped monotone executable. It doesn't work, because
the libidn-11.dll and libpcre-0.dll are missing.
eeks.
I added monotone-0.44-executable.exe.bz2 there, which is just th
Am 18.05.2009 19:01, schrieb "Marcin W. Dąbrowski":
Thomas Keller wrote:
monotone 0.44 was released today.
Two quickies:
http://monotone.ca/downloads/0.44/monotone-0.44-setup.exe
-> 404 Not Found
http://monotone.ca/downloads/0.44/mtn.exe
-> 403 Access Denied
Fixed, thanks.
Patrick
___
0 is unsigned int or void* and it has that method for both
- consistent const attribute for arguments of various methods (studio is
picky there, too)
As I don't know the impact on other platforms, I didn't want to commit
it myself. Feel free to pick the suitable parts.
Regards,
Am Dienstag, den 06.01.2009, 09:47 +0100 schrieb Markus Wanner:
> This is a bit off-topic here, but: is there a use case for revisions
> without *any* branch cert?
I think you get these if you pull a branch, which descends into other
branches that you don't pull
Regards,
Pat
or now.
The runtime effect was similar to yours.
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
ust move the //TRANSLIT stuff up into
> charset.cc and then go ahead with switching to the system installed
> libidn.
Isn't the //TRANSLIT//IGNORE thing a libiconv or gettext issue? It
shouldn't have anything to do with libidn in particular.
Regards,
Patrick Georgi
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
Am Tue, 6 May 2008 19:54:19 +0200
schrieb Thomas Moschny <[EMAIL PROTECTED]>:
> The problem is, that the all deleted files will have to stay in the
> rosters forever. This is not so much a problem storage-wise, because
Couldn't resurrection be done with a revision item like
resurrect "original pat
Am Sun, 04 May 2008 17:37:41 +0100
schrieb Bruce Stephens <[EMAIL PROTECTED]>:
> Patrick Georgi <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >> I'd have thought note_netsync_revision_received or something would
> >> be OK for that? Maybe one wants
Am Sun, 04 May 2008 15:22:54 +0100
schrieb Bruce Stephens <[EMAIL PROTECTED]>:
> [lots of good explanations about git branch names]
so it would be "mtn-wrapper changes-since-pull server branch", and use
a complete table of heads x server. okay..
> I'd have thought note_netsync_revision_received or
Am Sun, 4 May 2008 08:18:25 + (UTC)
schrieb Holger Freyther <[EMAIL PROTECTED]>:
> - git-rev-list origin/qtwebkit.. (to show what I would push now)
> is missing
What's origin - the last server you connected, or the default one?
It should be possible to track a list of head revisions per s
ibssl-using GPL sources
aren't build against such a replacement in the Debian repository (eg.
netatalk), I might be mistaken on it (or that project just isn't far
enough yet)
Regards,
Patrick Georgi
___
Monotone-devel mailing list
on of User and
Program directories, eg. in German Windows Vista, "Programme" is a symlink
to "Program Files", "Dokumente und Einstellungen" is a symlink to "Users",
for backward compatibility to older naming conventions while pro
last few years.
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Lapo Luchini schrieb:
> would be chibi, anyway), but about the de-iure-but-not-de-facto (yet :P
>
As for "yet": IEC 60027-2 (since 1999)
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://
ion
(it was hg2mtn in that case) instead of working around the differences
to get a suitable mtn-fast-import.
Regards,
Patrick Georgi
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
cvs2svn would use "automate put_revision" or
> something, and I suspect that'll be happy with any number of parent
> revisions.
>
There are a couple of invariants in the code that require revisions to
only have to ancestors. And I think some of the routines are hardcoded
for &
accepts empty changesets, though that should probably be prevented)
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
...
| $ sqlite3 openpkg-import.db .dump | sqlite3 openpkg-copy.db
...fails with lots of errors like:
how about using mtn db dump | mtn db load instead?
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http
he (small repositories
with lots of files changed in every revision?)
And yeah, a little code cleanup and some explaining comments would be
nice ;)
That's what I'll do next. Together with some improv.. ermm.. initial
work at a user interface. :-)
Regards,
Patrick Georgi
_
o contain merges that are invalid on monotone (revival of
files in a merge that were killed on one side) - hg2mtn fails with an
monotone invariant there.
As it's one of my first large python project "from scratch", it's probably
full of no-nos of python design. Patches welcom
ing about automate stdio and
transactions.
It might be good to provide an "automate commit" then (so that the user
of automate stdio can decide when to commit, eg. when a full revision
was pushed into mtn).
Thank you for the feedback!
Regards,
Patrick Georgi
__
he automate commands in
some other code path means that you get to do your transactions yourself
(and might forget them)
Comments highly appreciated :-)
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Markus Schiltknecht schrieb:
Can you run the testsuite on your solaris machine, too? Does the same
test fail?
Exactly the same situation, on various file systems - I would
investigate it, but time constraints forbid it for the moment.
Regards,
Patrick Georgi
#x27;t look too serious.
As a user of the Solaris build, I have no objections with this failing
test case to be ignored for this release (and be fixed eventually).
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://l
ng command] and
then run the failing command from the shell under truss(1) [strace(1)
is better if you have it] and mail in the complete output.
truss log attached. If there is anything more you need to know, I can
try to coerce dtrace into telling me.
Regards,
Patrick Georgi
clone-log.txt.
Richard Levitte wrote:
Question, are you getting the exact same error in a different Solaris
environment? I'd like to see a "second opinion", so to say. You see,
I'm wondering if zfs is coming into play here:
I had this test fail on nfs-on-ufs, too. (solaris express b63
haves slightly different than gnu's in some cases.
118 clone_warning_with_multiple_heads FAIL (line 21)
isn't one of the usual trouble makers, so probably a genuine bug - at
least I couldn't find anything suspect in this test
Reg
n for 0.36, but gcc passes all
tests except for calculation_of_unidiff (requires gnu diff in PATH - a
classic failure here, just ignore it),
clone_warning_with_multiple_heads, and clone_creates_right__MTN_options.
Regards,
Patrick Georgi
___
Mono
or a similar one) should really be
committed, but I'm not sure if it's actually the right fix for the
problem as I don't know enough about the template magic it changes.
Regards,
Patrick Georgi
___
Monotone-devel mailing list
g - and what about
date?), so this might be an alternative.
Can the above be implemented, or do you have another way to get commit messages?
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
wrong.
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
last bit missing in the gettext support rewrite.
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
adata (we can
extend the metadata of committed revisions using certs, hg doesn't seem
to be capable of such manipulations)
I don't have the time to work on this until late summer, but I could
post the (not cleaned up) parser bits that
presence of xgettext and msgmerge.
For this I need to know:
- which make targets do you want and what should they do
- what should happen automatically, and what not (eg. we had some magic
in configure to disable message catalog source rebuild on code changes)
-if-contents-unchanged logic as you see fit):
One issue: msgmerge doesn't seem to exist on Solaris (is it GNU?), so I
can't rely on that, but it's a start.
Thank you!
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@n
ferences on other platforms are more than welcome!
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Lapo Luchini schrieb:
Small poll: what database file does other people use?
~/{data,Documents,work}/monotone-databases/{monotone,my own stuff,other
stuff sorted approx. by project].mtn
Details depend on the pre-existing directory layout.
Patrick Georgi
s actually registered in inodeprints when it
(according to comments) shouldn't.
Anyway, with that state, I'm very happy
Again, Thank You!
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailm
tate of
the solaris packages was much worse already.
Thanks for the release effort!
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
next step, otherwise start at the next byte
- until iconv emits a response, push byte after byte into it
- skip that many bytes in the input, replace with one "?"
not so simple anymore, but imho still easier than integrating gnu iconv.
patrick georgi
___
similar to ACLs), and might or might not be available on
unixoid systems and to varying degrees.
A fork is just a separate stream in the file - a bit like if the file
was really a directory and the forks are files in that directory.
.. without a standard way t
Thomas Moschny schrieb:
This doesn't seem to be widely documented.
and neither widely implemented.
so gnu iconv becomes a dependency now?
patrick georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/ma
65 matches
Mail list logo
