Re: [Monotone-devel] information policy
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. > >> Its just that I have too many irons in the fire and serving many >> different media with basically the same contents just takes more time (I >> do write enough emails already to monotone-devel, right?! ;)) > > As long as it is clear how to integrate the RSS feed into typical > clients, that's fine. I get an RSS logo in Firefox (address bar, orange block, with 3 quarter-circles). Clicking on that registers the site's RSS feeds in my feed reader. Firefox takes its information about RSS from these lines in the website's HTML code: Maybe Gnus' could be taught to look for these when it's given HTML not RSS URLs? Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Please review nvm.automate_get_roster
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 not because it's too large (also not so unusual in web frontends) Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [IMPORTANT] Issue migration
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 snip (if iss...@host is the intended address) and regenerate any binary representation of it (newaliases(1) usually does this). Alternatively, if the user in question is an actual system user, add "|/usr/bin/..." in the users $HOME/.forward Either way tells the mail server to pipe incoming mail content to the command listed after "|" (pipe symbol). If you want to establish per-project addresses, many mailservers accept "user+somestr...@host" and pass those mails to "user". With that, the project could be parsed out from the mail recipient. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone idf implementation done
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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: removal of packet functions
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 simple than with darcs. What currently works is to manually collect relevant packets (revisions, files, certs) for explicitely given revs - that could be automated some more, but I think the consensus is to use patches instead (even if they lose some information) - they're much more approachable for humans. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] project status
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". The key is read and stored in > the database via automate. Come to think of it, the "first" key must be added by some non-automate means, right? So far, I use "mtn read" on the pubkey data to get the admin key into newly created dbs. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] project status
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 missing? First, the read_packet stuff might be dropped at some point (with all the other packet based CLI commands), as these seem to have fallen out of use. Second, Thomas proposed to add a "drop_key" command of some sort. While that won't help for already propagated keys (as those will come back), it allows the removal of just-added keys (ie. those added by mistake) For indefero it's not crucial to have a "get_key" command, not sure if there's an interesting use case for that. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 0.48 rants
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 commit message. > Why are date and author changeable? Surely these should be immutable > (apart from one could specify an alternate key on which to perform the > checkin - I assume that the same restriction applies when changing the > author in the changelog (i.e. you have to have a private key for that > user in your keys directory). There's a difference between author and committer (though by default they're the same). You can also do that pre-0.48 using --author, and change the date with --date, this change merely allows you to do that all at once in the commit message editor. The rationale is that you might want to commit something for someone else, eg. a patch sent to you. The "author" field gives attribution to the original author, while the signatures created with your key certify that the change was committed by you. For the same reason, people might want to change the date field. > I also agree that the changelog that the user enters should go at the > top. When working with GUIs you quickly learn that trying to slow a user > down and make him/her think about the consequences of what they are This wasn't about "think about the consequences", but about having a consistent layout for commit messages in log and commit. Probably misguided, but the only way to get reliable feedback is to have people use it - and it seems there was no-one who complained about it pre-0.48. I guess moving the changelog to the top (and all the metadata into commented lines below it) will go a long way to improve the usability of that feature. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] OS-specific line endings
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 support broken tools" is. That might be a deal-breaker for those who might want to use mtn but require such broken tools (with no short-term remedy). Your per-file attributes seem to be more useful (and can be easily provided defaults for by extending attr_init_functions). Maybe it makes sense to cache post-translation hashes for files with that attribute in _MTN, to have something to quickly compare against locally? > If we have a way to call an appropriate hook in calculate_ident, then it > can be used for any symmetrical file munging; line endings, character > set conversion, encrypting, etc. character set translation isn't necessarily symmetric. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] OS-specific line endings
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 be seen as binary but aren't
> obviously so from a technical point of view.
How about a file $root/.mtn_newlines with [binary] and [text] sections,
and glob patterns in them ("*" for default) to match against?
"binary" should be mtn-default for all files, as it's the non
destructive option.
Patrick
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] is monotone for me?
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 interprets the git-fast-import
format and creates a monotone repository from it.
I didn't work on export due to lack of need, and dropped work on it in
favor of hg2mtn, which directly uses hg metadata (which is less lossy
than hg->git->mtn) which was my primary concern.
I put up the code at https://code.georgi-clan.de/p/hg2mtn/ but didn't
test/use it in a long time. Feel free to try it, and to report issues.
I'm also on IRC (irc.oftc.net, #monotone), but I might be a bit slow to
react for the next two weeks.
Regards,
Patrick
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Extended selectors
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 ancient shell for pipe, so it's just as fragile (with the additional disadvantage that people don't know about it anymore). Parentheses must also be quoted for some shells, so it's probably okay to just use | (which is probably more commonly understood as 'or' due to regular expressions using it), and expect users to understand that they'll need quoting, like in the example above. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] anonymous pulls
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
Re: [Monotone-devel] cvs_import failure
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 once that I wanted to use with a mercurial-to-git exporter, and dropped it in favor of building my own hg2mtn parser. The reason is that the git-fast-import format is quite specific to the design of git. For example, while git-fast-import (later on) gained rename tracking, it's still optional - as git doesn't care for it anyway. In the end, I had to resynthesize various pieces of data that existed in the original format and were lost in the hg->git step. I'm not sure if that applies for any svn2git translator, and if desired, I can look if I can find my (old) mtn-fast-import tree somewhere. Regards, Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Some numbers for push/pull to/from a memory database
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 since each pull method (db vs memory-based server) suffers > from the same, the CPU should be actually irrelevant in this comparison. > > What I have not expected is this very high user time for pulling > nvm.guitone, so lots of work seems to be done in the client here. I > haven't tuned forward / backward delta usage with the server > configuration, maybe this would have helped a little bit here. Out of curiosity, how large are the trees pushed there (in number of files)? The code scales with the tree size, instead of delta size in some places (that also affect push and pull). (see http://article.gmane.org/gmane.comp.version-control.monotone.devel/16424 ) That code is CPU bound and has nothing to do with the database. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Roster handling in the code
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 some groveling over the exact definitions of the various cset operations and probably some additions to the Giant Roster Tests to make sure the results are the same with/without the optimization. The other way would be to teach the roster+cset -> new roster code to keep a list of dirtied nodes, but that might be tricky for merges, I forget. I tried these (and more) and failed to find my way around the code base to fix this. That's probably due to my lack of c++ experience (both language and best practices), but well.. I'll have to give up, also because this exceeded the time I could allocate to this issue. Just wanted to note that this issue is unclaimed again. The auroraux project is ran into this issue, so if someone here wants to spend some time, and has more experience with the codebase, and wants to help a project with 50k files in the tree, this would be a good opportunity. It also seems to be a smaller issue than policy branches ;-) Regards, Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Roster handling in the code
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 with trees with 5 files - comparing all of their entries
just to find the 5 that actually changed is quite a waste of time.
As a test, I disabled the roster deltification code, and got quite some
speedup (pushing 10 revisions with put_revision in approx. half the
time), so there's definitely room for improvement.
I think the main motivation for roster_deltas is database size. If we
can store a new revision as an old revision plus a small delta, that's
a significant size saving. As with anything that saves size, it costs
computation time. Which doesn't mean the current trade-off is optimal.
Disk space is certainly cheaper than it used to be. But so is CPU time
:).
Perhaps a user tuning option could be provided?
The problem in this case, that large trees affect both of them very
negatively. When I did the profiling, I disabled roster_delta generation
(#if 0/#endif around a couple of lines in database.cc) to see if I'm
really on the right track.
But this "optimization", while reasonable for small trees, really hurts
large trees, too. Every roster contains information about 5 files,
and that sums up.
So both potential optimizations, the current one, and disabling
roster_deltas, are acceptable for small trees. But small trees are not
the case I'm looking at.
...
My current approach is to try to create the roster_delta while the new
roster is created out of the old (using
cset.apply_to(editable_roster_for_{non,}merge)). The most appropriate
place for this seems to be editable_roster_for_{non,}merge, as all data
is passed to it as some point of the operation.
I have wondered why there were two different "delta" mechanisms; one
that creates changesets, and one that creates roster deltas. I thought
at one time that one could be eliminated. But then I realized both are
needed. I'm not sure I can remember the details, though :(.
I think at the time where changesets are created and written to the
database, some data that's stored in rosters (and thus roster_deltas)
isn't around yet, for example node ids.
It could be that combining them would lead to a time savings.
The ability to generate one out of the other, given the right set of
source data, might be enough. As changesets are managed first, my
attempt is to efficiently generate roster_deltas out of changesets plus
the related rosters.
But I'm looking for a more direct approach: Is there a way to get figure
out the revision that matches a roster?
Rosters are fetched in the first place by revision id, so I'm not sure
what you are asking.
I was deep inside the code, and at some point, it was only shuffling
rosters, with no revision ids in sight. I just looked a couple of levels
further up, and everything needed seems to be there.
For example:
db.get_roster(left_rid, left_roster, left_marking_map);
db.get_roster(right_rid, right_roster, right_marking_map);
This is from the merge code. If you could point to the section of the
sync code you are worried about, it might help.
This gave me an idea: database::put_roster handles the deltification of
rosters. The revision ids are available there, so I could hand over the
changesets to the delta_rosters(...) call there. See below.
5 lookups instead of 5.
Computing a roster delta should not involve retrieving the file text
for every file; doesn't it check if the file id (hash of the contents)
has changed first? Those are given in the roster, so comparing them
doesn't count as a "lookup".
Yes, but look how it's done. It's in roster_delta.cc,
make_roster_delta_t(...):
It creates a datastructure containing information about _all_ files in
the roster (ie. all 5 in my case), and then loops over them and
notes the differences.
The cset already contains a list of all changes between the two
revisions, so the code could walk a changeset to figure out which roster
entries to handle. As most changesets are rather small, that should give
a nice speed up.
What are you defining as a "lookup"?
This iterator is used to look up the changes: parallel::iter
i(from.all_nodes(), to.all_nodes());
Regards,
Patrick
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Roster handling in the code
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 the tree size). The problem is, that I'm
working with trees with 5 files - comparing all of their entries
just to find the 5 that actually changed is quite a waste of time.
As a test, I disabled the roster deltification code, and got quite some
speedup (pushing 10 revisions with put_revision in approx. half the
time), so there's definitely room for improvement.
The pattern, to compare all entries, appears several times more in the code:
parallel::iter i(from.all_nodes(), to.all_nodes())
sometimes with other names for "from" and "to", so more parts of
monotone might benefit from such an optimization.
My current approach is to try to create the roster_delta while the new
roster is created out of the old (using
cset.apply_to(editable_roster_for_{non,}merge)). The most appropriate
place for this seems to be editable_roster_for_{non,}merge, as all data
is passed to it as some point of the operation.
But I'm looking for a more direct approach: Is there a way to get figure
out the revision that matches a roster?
>From there, it should be possible to find out the changeset between the
two revisions, which contains most of the data a roster_delta contains -
basically everything but node_ids and markings, if I'm not mistaken -
and those can be fetched out of the rosters, given the cset data. 5
lookups instead of 5.
If anyone has ideas on how to improve this area in a better way than
what I tried to describe here, I'd be grateful to hear them. I'm not
that used to the monotone code base, and this is the first time I really
dive into it.
Regards,
Patrick
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANN] monotone 0.44 released
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 the libraries that you want to statically link. There's an easier way (and in fact the only one that still works on solaris these days): Replace -lbotan (etc) with path/to/libbotan.a (etc) That way, libc and various other stuff is still linked dynamically (on Solaris, there is no static libc anymore) monotone's configure flags allow such a configuration: sqlite_LIBS=$TARGET/lib/libsqlite3.a etc. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANN] monotone 0.44 released
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 automatically picks up the static libraries. We should use the Makefile in the distribution, unmodified. I had to patch some source files (some #include and using std:: statements, as usual - cleaned up patch will appear soon), but the build system was unchanged. I don't know if Inno setup is intelligent enough to check for the existence of the dlls, and only install the missing ones. Or to install them in a better (shared) place. That's something we should look into. shared place? unversioned shared libraries? Doesn't sound like a good idea to me. At the very least, the build instructions in INSTALL and win32/README should be kept up to date, and produce the setup executable on the website. Probably. In that case, I can't do it, as with shared libs, it doesn't build right (thanks to some mangling related to imported symbols) Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANN] monotone 0.44 released
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 but no dlls; I've now replaced it with the correct version. I prefer to build monotone static (also on Solaris), and the mtn.exe I posted works. Using dlls is especially useless as mtn has its own private copy in that setup. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANN] monotone 0.44 released
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.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANN] monotone 0.44 released
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 the executable, needing no external libraries, compressed with bzip2. I don't know enough about the installer stuff, so I can't do that for now. Not sure if that should end up on the frontpage, either. Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANN] monotone 0.44 released
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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [PATCH] to make monotone build on OpenSolaris
Hi,
I updated my packaging for monotone to 0.43. I still have to look at
getting more libraries linked statically before I can upload packages to
monotone.ca again, but that will eventually be done.
In the course of it, I collected a couple of (usually minor) changes to
get monotone to compile on Solaris with the Sun Studio compiler, and you
can find them in the attached patch, which is against net.venge.monotone.
- import more stuff from std:: and Botan:: into the globally visible
namespace
- clarify method selection for .insert(0,...) where studio isn't sure
whether that 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,
Patrick Georgi
#
# old_revision [3836166c60e4ab6cbdceb302f0958b09a7f51992]
#
# patch "automate.cc"
# from [3f693194a9de3cb8e5214dd13608103597a7f737]
#to [9c4d225aab0e5ce122674ac2bb6921ee6b0d9f6e]
#
# patch "database.cc"
# from [45a853c398d98224ff998f8769cf4dcbbb0a7d40]
#to [1cd8904da0236db3a8c5b7d49ed29e3d651ba3df]
#
# patch "key_store.cc"
# from [459dd9ae128419afaaa65dd6bb7d3d725a32f207]
#to [64895846df02b282dca51a0c39512fed56212b3c]
#
# patch "merge_conflict.cc"
# from [bcc2018db31c73b7a6a63135e42095127217951d]
#to [5a0307cd2d52e0fe6201428bda86121cdeea515a]
#
# patch "merge_content.cc"
# from [b7b36faae51fad93a1b7ba37c17eee7bb20dd5a9]
#to [758caf01d627a675e28dd169289c9f15fa69433e]
#
# patch "txt2c.cc"
# from [77e55cb6174483c2e253052793a5fc15e43535d2]
#to [b23798126943239eaff66187b8828e153ec2c8d8]
#
# patch "unit-tests/roster.cc"
# from [e591ab4c78e425d2ae7140eeb4103746b0bc74e9]
#to [b97daa78753cf898ab900a2ccf53a458d108849a]
#
# patch "unit_tester.cc"
# from [28af6bab67aa693109a382dcd1eb35628030fb13]
#to [4316ae3e819115403a1f305e84c05291acc43b24]
#
--- automate.cc 3f693194a9de3cb8e5214dd13608103597a7f737
+++ automate.cc 9c4d225aab0e5ce122674ac2bb6921ee6b0d9f6e
@@ -50,6 +50,7 @@ using std::char_traits;
using std::basic_ios;
using std::basic_stringbuf;
using std::char_traits;
+using std::find;
using std::inserter;
using std::make_pair;
using std::map;
--- database.cc 45a853c398d98224ff998f8769cf4dcbbb0a7d40
+++ database.cc 1cd8904da0236db3a8c5b7d49ed29e3d651ba3df
@@ -81,7 +81,9 @@ using std::pair;
using std::multimap;
using std::ostream;
using std::pair;
+using std::remove_if;
using std::set;
+using std::sort;
using std::string;
using std::vector;
using std::accumulate;
@@ -98,6 +100,7 @@ using Botan::RSA_PublicKey;
using Botan::SecureVector;
using Botan::X509_PublicKey;
using Botan::RSA_PublicKey;
+using Botan::get_pk_encryptor;
int const one_row = 1;
int const one_col = 1;
@@ -973,12 +976,12 @@ database::info(ostream & out, bool analy
= max_element(counts.begin(), counts.end(), longest_number)->length();
for(vector::iterator i = counts.begin(); i != counts.end(); i++)
if (width > i->length() && (*i)[0] != '[')
-i->insert(0, width - i->length(), ' ');
+i->insert(0U, width - i->length(), ' ');
width = max_element(bytes.begin(), bytes.end(), longest_number)->length();
for(vector::iterator i = bytes.begin(); i != bytes.end(); i++)
if (width > i->length() && (*i)[0] != '[')
-i->insert(0, width - i->length(), ' ');
+i->insert(0U, width - i->length(), ' ');
}
i18n_format form =
--- key_store.cc459dd9ae128419afaaa65dd6bb7d3d725a32f207
+++ key_store.cc64895846df02b282dca51a0c39512fed56212b3c
@@ -52,6 +52,8 @@ using Botan::Pipe;
using Botan::PK_Decryptor;
using Botan::PK_Signer;
using Botan::Pipe;
+using Botan::get_pk_decryptor;
+using Botan::get_cipher;
struct key_store_state
{
--- merge_conflict.cc bcc2018db31c73b7a6a63135e42095127217951d
+++ merge_conflict.cc 5a0307cd2d52e0fe6201428bda86121cdeea515a
@@ -673,7 +673,7 @@ roster_merge_result::report_invalid_name
roster_merge_result::report_invalid_name_conflicts(roster_t const &
left_roster,
roster_t const &
right_roster,
content_merge_adaptor &
adaptor,
- bool basic_io,
+ const bool basic_io,
Re: [Monotone-devel] git fast-export
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, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtndumb & public cert_id
Am Mittwoch, den 17.12.2008, 13:14 +0100 schrieb Zbigniew Zagórski: > Regarding timing: > > For my private database (~1200 revs): >old approach 15s(~1200 automate calls) >new approach 2s (~15 automate calls) > > For net.venge.monotone db (14348 revs): >old approach 180s (~14400 automate calls) >new approach 10s(~70 automate calls) > > These are _very_ manual tests and take into account whole process > running, including spawning python, monotone. BTW, on linux timings > are usually twice as faster for old approach so win32 is > also an issue. I worked around a similar issue (I have to get a table of all revisions with a given cert, and the value of that cert) in my hg2mtn tool by querying the database directly (mtn db execute). Of course, that's an unstable interface, but it works for 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
Re: [Monotone-devel] Re: nvm.stripped
Derek Scherger schrieb: > On Sun, Oct 12, 2008 at 2:49 PM, Zack Weinberg <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I put some patches on .library-build to deal with this. The 'best > effort' functionality is not available in 1.5 as far as I know, but I > don't know any reason why the //TRANSLIT//IGNORE thing that we had > before the 'best effort' patches isn't good enough... Lapo is perhaps > > > That's what I was wondering too. I also wonder if maybe libidn might > have fixed the problem in the intervening 5 years since Graydon > grabbed a copy. IIRC Lapo was fighting with the changelog comment on > one particular revision in the monotone history. It would be > interesting to have this test case if we can dig it up. In the > meantime I'll probably just 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn2git issues
Felipe Contreras schrieb: > 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. > Did you try rosters? They're an internal representation of manifests (with some differences, they contain some data specific to the local repository, which you might not care about), and they're also stored in delta format, like manifests. Maybe access is still faster (because they don't need as much validation, as far as I know) For git, you want to know how the tree looked at specific times (snapshots), but the native data exchange format in monotone is changesets (what you get with get_revision - it tells you what 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
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
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 path" from [ancestor rev] as "new path" with "content hash" ? This way, the file would be "truly dead" inbetween (rev 5 in the example below) and doesn't have to be kept in the roster. The resurrected file would get the old node-id (not sure what should happen with the birthmark). To make this "safe" (so two revisions that resurrect the same file get the same revision text - we do quite some ordering and checking in the revision basic_io format, to ensure a well-defined format), this could require that the ancestor rev is the one where the file was deleted, but: 0 file a exists / \ 1 3 file a is changed (differently in both 1 and 3) | | 2 4 file a is deleted (both in 2 and 4) \ / 5 | 6 file a is resurrected Which version should mtn resurrect? (it could ask the user, but we don't do that for other non-content issues, so what would be the default?) Regards, Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: OpenEmbedded looking to jump ship
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 a hook that receives all the > >> revisions in one go or something? > > hmm.. initialize a branch list at the beginning, then check each > > incoming revision - could work.. thanks, I didn't think of the > > hooks! > > Maybe the existing hooks are sufficient, actually. Or do hooks get > evaluated in different lua interpreters? If they're evaluated in the > same one, then you could presumably code up something using > note_netsync_start, etc.? that's the idea. extra/display_branches.lua (thanks Richard Levitte for it, and Stephen Leake for the hint) does half of it: displaying all affected branches. Adding a way to denote new branches shouldn't be too hard. > So mostly you use rebase on local work---you commit when it makes > sense, and then reorganise the changes. Perhaps to improve the > reviewability of the changes, or in response to review, or maybe just > to incorporate upstream changes (you can merge, of course, but > sometimes it makes just as much sense to linearise the changes by > moving your changes to the current head). Basically mtn-plucking a set of revisions to somewhere else, while giving the head of "somewhere else" a suspend cert. That will make the repository grow a lot, of course (as we don't throw away things)... If someone else already worked from the old head, things will be messy: two heads with "unrelated" changes (esp. for new files and the like!). I'm just trying to wrap my head around how such things could be approached. > > Which is why I still think that rewriting history is a bad idea. > Perhaps. I'd just comment that git users seem to find it works fine > and is valuable. I think perhaps you're imagining it gets used in > problematic situations where it (mostly) doesn't. We thought that would be the case for certain currently problematic non-content merge scenarios, too... Together with that "heads-on-server" tracking (for looking for local updates) and the validation if you're working on uncommitted revisions (which could then even be kill_rev_locally'd), that sounds possible and reasonably safe. > > For monotone it would be more like "reapply (from, to) to (new base > > rev)". That isn't _too_ different from just merging.. (just that > > you have one new revision at the top, instead of 250 revs. copied to > > a new location in the DAG) > > Maybe, though that would only be one part of what "rebase" is used > for. The other(s) being? Regards, Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: OpenEmbedded looking to jump ship
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 something would be > OK for that? Maybe one wants a hook that receives all the revisions > in one go or something? hmm.. initialize a branch list at the beginning, then check each incoming revision - could work.. thanks, I didn't think of the hooks! I'll try to implement those two things next week. > I'd guess a lot of the other stuff probably relies on git's > implementation: the DAG contains no branch information, branches are > files containing the hash of the branch head. So amending the last > commit is easy, you just create the new commit and move the branch > ref. Similarly you can rewrite sequences of commits in the same way That could be done by monotone easily, too - but if your previous revision was pushed, you have two heads now (just that git doesn't allow for that, "solving" that issue and leaving the old rev for the garbage collector, because you push a new head at a completely different location. ... unless someone else started work from your old head already - right? Which is why I still think that rewriting history is a bad idea. For monotone it would be more like "reapply (from, to) to (new base rev)". That isn't _too_ different from just merging.. (just that you have one new revision at the top, instead of 250 revs. copied to a new location in the DAG) Regards, Patrick ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: OpenEmbedded looking to jump ship
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 server (or the default one, etc.) after each pull or sync, and use "automate ancestry_difference" to calculate that. I'd write a wrapper-script for that (as proof of concept, at least), if we get sorted out, what to check against. > - gitk is almost instantly working on the OE tree what's the complaint here - speed? features? > - git-fetch will tell me what was updated, which branches > created, mtn doesn't have this. Again, I could write a wrapper script for that (though an inline variant would be more efficient, avoiding the second "ls branches", by looking at the incoming packets): ls branches, pull, ls branches, diff (I only offer to do wrappers because I don't know the monotone code base enough for a full integration, and I don't have time currently to figure it out.) > I feel forced in a work flow: > - git-commit --amend is missing > .. > - git-rebase -i is missing These two (at least) change history. Monotone has immutable history, which is a feature. (amend-commit as a shortcut to kill_rev_locally, then commit could work) As for the other "forced to a work flow" issues, I don't know what the git commands provide (and I fear that I won't get a 100% idea from reading the docs) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
[EMAIL PROTECTED] schrieb: There's the libssl package in Debian. aptitude tells me Description: SSL shared libraries libssl and libcrypto shared libraries needed by programs like apache-ssl, telnet and openssh It is part of the OpenSSL implementation of SSL. Is that at all relevant? Take a hard look at licensing. libssl was (last time I looked) 4-clause bsd licensed (bsd + advertising), and thus triggered the license incompatibility mode of the GPL. There might be some GNU/GPL rewrite of it - at least something along that lines was planned. But given that other libssl-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 Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] symlinks support [Was: Future of monotone]
On Mon, 28 Jan 2008 10:27:57 +0100, Lapo Luchini <[EMAIL PROTECTED]> wrote: > AFAIK Windows doesn't really have anything close to symlinks (natively). Vista has (on NTFS, but who actually uses FAT for the hard disks these days?), and uses them to fix the issues around the localisation 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 providing more consistency now. Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone on n800 - mtn: error: sqlite error: file is encrypted or is not a database
Am Mittwoch, den 19.12.2007, 09:15 +0100 schrieb Koen Kooi: > * no locking support in your FS (e.g. mtn doesn't work on nfs) For the record, I used mtn on nfs, and it worked just fine (even if a bit slow). Though that was on Solaris and I have no idea if linux-nfs finally caught up in the last few years. Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] kibi!
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://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Bruce Stephens schrieb: > cared about this could hack a monotone backend in a day or two; > maybe longer if it turned out that monotone needed extra automate > features, but I'd guess it wouldn't now that there's a way to > commit revisions. automate is definitely enough for hg2mtn... > For that matter, I guess it might be feasible to read git's > fast-import format instead (that would probably take a bit more > effort, but might be more useful). I started such an effort, but considered it not worth it, as fast-import reveals too many of the details in git's design that differ from monotone. I particularily had issues with the differences in branches, and it was seriously slowed down by keeping my own directory tree model (as git doesn't handle directories at all). Summary: I got better results quicker by building a direct translation (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
Re: [Monotone-devel] Re: Request for help adding monotone output to cvs2svn
Bruce Stephens schrieb: > I don't think monotone has such a restriction. I think it happens not > to create such revisions at present, but I don't think there's any > intrinsic requirement that a revision has at most two parents. I > imagine an importer from 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 "either one or two ancestors", too. Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Initially creating a branch without committing changes?
Ralf S. Engelschall schrieb: > $ mtn cert h:foo.bar.cvs branch foo.bar > > This worked just fine. But I'm not sure whether whether this really is > the correct approach. > This is the correct approach. Propagating into empty branches would lead to lots of typo-branches (net.vnege.monotone.foo and the like), but adding --force to propagate might work, too. As for empty changes, I'm not sure if they are a good idea (and the UI prevents them, as you noticed). With enough sophistication, you could easily add them, if you really need them (put_revision - it happily 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
Re: [Monotone-devel] SQL logic error, SQLite restore problems, etc.
Ralf S. Engelschall wrote: 1. copying repository via raw SQLite dump/restore fails This is actually an SQLite problem (and I will forward to the SQLite community, too), nevertheless you should be aware here, too. A simple... | $ 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://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] hg2mtn 0.0.20070824
Thomas Keller schrieb: I'm a Python novice myself, so I can't give you much advice (despite I don't like "tmp"-named variables very much in any language ;). However, by skimming through your code I found this: Those are fields I simply don't care about - hence "tmp".. mercurial doesn't seem to expose the interesting bits separately (and they exist in a single data structure in revlog, so it would likely be more expensive, too) # FIXME: handle renamed files ofctx = parentcontext.filectx(file) oldid = sha.new(ofctx.data()).hexdigest() This looks like you're hashing the old file contents for each patch you are going to feed into mtn, right? Wouldn't it be better to use some kind of cache here, since if you process the revisions forwardly, you should already know all the fileids from previous revisions, don't you? Maybe this could speed up the thing a bit more. That would mean I'd have to keep the manifests around (but with monotone's hashes, as mercurial gives me some "other" data), and copy the stuff appropriately. I'd also need to handle the case where the manifests don't exist (incremential update) For my purpose (35000 files per manifest, usually less than 10 patches), I think the brute force way I implemented is more efficient, esp. as access to file data in mercurial is very fast. I'm not sure at which point it would be more efficient to keep that cache (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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] hg2mtn 0.0.20070824
Hi, I hereby do the first public release of hg2mtn, an importer of hg repositories into monotone. It's licensed under GPL (v2+) as it makes use of other GPL components. I first tried to write something general based on an implementation of the git-fast-import interface for mtn, but that wasn't such a good idea as it basically results in two lossy steps: whatever-to-git-semantics and git-semantics-to-mtn, so I wrote a direct hg2mtn importer now. At this time, it lacks all the usability bits (like getopt parsing, a tarball release, or sane user feedback). It requires the automate stuff of tracvc. It's probably easiest to just have the whole tracvc tree in the PYTHONPATH for now. It also requires an installation of mercurial (it basically uses its code to read the repo) The location of the hg repository, the mtn repository and the branch where all the hg stuff should end up are set in some variables in the source. I also recommend adding a transaction guard to automate stdio because mtn commits every single put_file, which leads to a massive slowdown (at least on some filesystems - on ZFS it's 4 minutes instead of 20 now) For now, it stops execution after 50 commits, you can restart and it will skip the existing revisions (that's partly a work around for the transaction guard - it really requires an "automate commit" command, so that at certain points the database state can be frozen, as otherwise all work is lost on ctrl-c). Export to mercurial shouldn't be too hard (the import keeps the hg revision as cert to every mtn revision), but that's beyond the scope of my work for now. Also missing (but on my TODO): - handling of hg tags - handling of whatever rename facility they have Some hg repos seem to 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 welcome and accepted! Regards, Patrick Georgi hg2mtn.py Description: application/python ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Speeding up automate stdio
Nathaniel Smith wrote: This last part sounds like a bug -- transaction guards are supposed to nest, so that if we are already in a transaction all that they should do is increment a variable somewhere. Hmm.. Did I forget the bit about the unscientific benchmark? Maybe that fooled me here (but 4:00 -> 3:30 seems to be a large error margin) I also read the code wrongly and thought that the guards commit every x-th invocation, but that's actually a checkpointing mode. Fixing this would help with some of your later concerns about removing transaction guards as well, since there should never be any reason to remove a transaction guard... In this case, this change would be trivial (add an option, look for it and create a global transaction guard) You might also want to look into the "checkpoint" (IIRC it's called that) functionality, if you're thinking 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Speeding up automate stdio
Hi,
I'm still working on an hg2mtn facility and tried to import the files of
the first revision of that hg repository (34000 files) with automate
stdio using the put_file command.
On my regular filesystem (ZFS), it took approx. 20 minutes.
For fun, I tried again with the monotone repository on tmpfs (swap based
ramdisk), and came out with only a bit more than 5 minutes.
ZFS is usually a pretty fast filesystem with aggressive caching before
it writes to disk, but it wrote small chunks to disk all the time - so I
blamed transactions, and added a big transaction in automate stdio
around "everything".
With that change, it took only 4 minutes on tmpfs, and feeling more
courageous, I removed the transaction guards in put_file (there's a big
one around it, after all), which gave another 30 seconds.
Then I tried on ZFS again - and it finished in 4:50, so it's 4 times
faster! (for this absolutely non-scientific and specialized test)
What to do with it result: I'm thinking about adding an option to
automate stdio that tells it to use one global lock
("--all-or-nothing"?) and disables the transaction guards for every
single commands it calls, but I wanted to discuss it first, as I have no
idea what kind of impact such a change might have.
I'm thinking of implementing it as follows:
- add a transaction_guard around exec_from_automate(..) invocation in
"automate" (non-stdio)
- add an optional transaction_guard around exec_from_automate(..) in
"automate stdio"
- add global transaction_guard in "automate stdio" (or not: that should
be covered by the first change already)
- remove all old transaction_guards in automate commands
I see one problem with this change: Reusing the 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
Re: [Monotone-devel] Re: Imminent release...
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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Imminent release...
Markus Schiltknecht schrieb: But most probably monotone didn't work and hasn't been used much on AIX or Solaris. At least on Solaris I use it daily and without serious issues. Notice, that the Solaris build is mostly broken because of one corner case in mtn clone, which doesn'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://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Solaris breakage
Zack Weinberg wrote: Aha, you're the one with the Solaris box! Please do exactly what I suggested in my original comment on this problem - run the test case up to right *before* the failing command [put "check(false)" in the relevant __driver__.lua, immediately before the failing 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.bz2 Description: application/bzip ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Solaris breakage
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) Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] First things first...
Richard Levitte schrieb: failures on Solaris (see http://monotone.ca/buildbot/sparc-solaris10-sunstudio11/builds/25/step-test/0). 97 calculation_of_unidiffs FAIL (line 26) likely fails because it's using sun patch (which is the default in the path) which behaves 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 Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Build errors with VC8
Richard Levitte wrote: Good, I'll try it on my systems and go from there. It's promising, since it seems to fix Solaris problems as well... I found it to break gcc3.4 on solaris, though - but maybe you fixed that problem while merging? As for solaris, sunpro support is broken 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Build errors with VC8
Anthony Williams schrieb: Attached is the output of mtn diff on my workspace. This patch also helps with join_words<> issues on sunpro. Thank you! I still have some other issues on runtime, but I don't think they're related to this change. So in my opinion, this patch (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 Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] No read-only automate cert (aka no mtn2cl)
Koen Kooi schrieb: The gist of the problem: 'automate cert REVISION-ID NAME VALUE' should be 'automate cert REVISION-ID NAME [VALUE]' 'automate certs REVISION-ID' emits all certs of a revision. For your example you need two certs anyway (author and changelog - 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
Re: [Monotone-devel] linus talk on git
Florian Weimer schrieb: But in this case, CR+LF is the Internet standard. not only that, it's quite an universal standard. after all, look at the original meaning of CR and LF: carriage return: x=0 line feed: y+=1 mac implie[sd] y+=1 on CR, unix implies x=0 on LF, and both are wrong. Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] In preparation for the next release: Translations look good!
Richard Levitte schrieb: In my self-proclaimed role as translation police, I just had a check, in your self-proclaimed role as translation police, would you mind telling me what kind of developer tools, that is, makefile targets, you need in that function? ;-) they're basically the 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
Re: [Monotone-devel] monomercurial sync
Lapo Luchini schrieb: Or is anyone aware of an existing such project? I've been working on a c++ parser of hg's revlog format. I think I understand most of the format now, but some parts are missing: It needs an implementation of hg's delta algorithm and some more magic to link the manifest table with the file data files and general handling of all that. A hg checkout keeps lots of files in revlog format, maybe a bundle is easier to manage, but I didn't look at those yet. With those additions, it should be quite easy to fetch the manifest tables, their changelogs (including data that would end up in author and date certs) and all full versions of changed/added files. From there, the monotone data could be synthesized. I haven't thought much about the other direction, but there are some issues with the flexibility in how monotone stores metadata (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 I have somewhere. Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] portable-gettext-support
Hi, on net.venge.monotone.portable-gettext-support, I'm working on support for NLS on systems without GNU gettext installed (incl. the capability of building configure scripts without gnu gettext m4 files and their dependencies). I think it's at a point where more testing and feedback is required. For gettext support, there are two aspects to cover: The user side (those who want to build NLS enabled monotone), and the developer side (those who want to maintain languages). I think the branch is basically complete on the user side: - it looks for the tools - it provides a way to disable NLS altogether if you don't want it - it disables NLS if the tools aren't enough - it builds the .mo files from .po files - cleans up properly - installs properly TODO: (if I missed anything, please say so) - make more robust if necessary (for this I need testing) - figure out how to determine if .mo or .gmo is the right suffix for the message catalog objects. (currently it always builds to .mo) - remove the obsolete files in po/ (I'll do this after the development stuff works) The developer side is basically non-existant right now, it only checks for 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) Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Translations revisited
Zack Weinberg schrieb: essay "Recursive Make Considered Harmful" [ http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html ] for rationale. You're right - it's a matter of reuse, but I can probably get that even better with some more autoconf scripting, too (eg. have configure/automake/whoever fill in the appropriate section into the Makefile). Thanks for making me rethink the current layout! Also, please do not bother preserving Makevars, LINGUAS, or any other such construct that is not actually necessary. In my ideal world, I'm not quite sure about getting the languages automatically - after all, we also don't just import *.cc. But the impact is smaller here, so I wouldn't argue too much about that detail. Any other opinions/preferences on this? I would thus suggest rules like this (add extra atomic update and/or no-change-timestamp-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@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Translations revisited
Richard Levitte - VMS Whacker schrieb: I'm looking at the translations done until now, and this is what I get: I'm currently looking at what functionality the Makefile in po/ has to provide for devs (besides .po -> .gmo/.mo parsing), because I intend to remove the dependency on gnu gettext there. Currently, the Makefile in po/ is created by autopoint, a component of gettext. I already rewrote the autoconf tests (as they're also provided by gnu gettext - see nvm.portable-gettext-support), but they still need some work, and now making that Makefile.in static is my next step. so, what's necessary? - .po -> .gmo/.mo compilation, with using LINGUAS and Makevars as appropriate - autoconf tests to figure out which tools to use and which features they provide (eg. most of Makevars is utterly useless with solaris' gettext variant) - xgettext runs to extract new versions of .po (into .pot, it seems) - run of msgmerge where available to merge .po and .pot into a new version anything else? or is any of these not actually in use? Also, if the Makefile.in.in in po/ exists, the branch mentioned above should compile just fine - at least the configure step runs through and creates all variables (with the single known issue, that ENABLE_NLS isn't disabled if HAVE_GETTEXT and the like are disabled because the libraries can't be found) However there was no testing on non-solaris platforms yet, reports if there are any differences 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
Re: [Monotone-devel] where to put a (default) database? [Was: clone cleanup failure on Windows]
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
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Tests passing!
Replying to myself: 184 i18n_commit_messages FAIL (line 22) This fails because it relies on //IGNORE//TRANSLIT (or //IGNORE,TRANSLIT, as drepper claims - whatever): gnu iconv feature 263 multiple_version_committing FAIL (line 15) 264 netsync,--exclude,defaultsFAIL (line 3) Spurious failures, pass now - maybe related to high load/low memory situation. 385 two_parent_workspace_inodeprint_from_birthFAIL (line 59) Absolutely no idea what happens here - the check in line 59 of the test fails because "left" is 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/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Tests passing!
Richard Levitte - VMS Whacker schrieb: All tests are passing on revision 22c1303469c2c43156c727f0fd64d40aca9f76c3. Unless something else happens, that's going to be the revision I base the release of 0.33 on (after having corrected silly stuff like documentation, version number changes and such). On Solaris/x86, this passes all tests except: 88 calculation_of_unidiffs FAIL (line 26) 184 i18n_commit_messages FAIL (line 22) 198 largish_file FAIL (line 28) 263 multiple_version_committing FAIL (line 15) 264 netsync,--exclude,defaultsFAIL (line 3) 275 netsync_largish_file FAIL (line 11) 385 two_parent_workspace_inodeprint_from_birthFAIL (line 59) 88, 198 and 275 are expected (88 expects gnu diff but gets sun diff, 198 and 275 don't get enough memory here) 184 is also somewhat expected given the sorry state of support for non-gnu gettexts (I'll be working on that soon) So 263, 264, 385 remain which I have to check. But given that everything else works, I'd have no issues releasing such a package, the state 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
Re: [Monotone-devel] iconv diffs [Was: Why is utf8...]
Nathaniel Smith schrieb:
have no idea what's going to happen on, say, OSX or *BSD or Solaris.
For solaris: it will fail as it can't find that table you refer
("ASCII//whatever") as it's non-standard.
The same for BSD, unless they rebuilt the GNU extension (in which case
you'd better look out for implementation differences)
One option is just to write our own "//IGNORE"-style iconv wrapper.
iconv's normal API is that it does as much work as it can, then it
tells you where it bombed out. It's perfectly possible at that point
to skip ahead a byte or more on the input, stick a question mark in
the output string, and then try again from there. Not the most
efficient thing in the world, but probably a lot easier than trying to
ship iconv conversion tables.
"skip ahead a byte" is troublesome - if your illegal sequence is a
multibyte character (or even some state machine changing sequence in
some of the obscure encodings), your next character will be wrong or
illegal, too.
but skipping a character should be possible:
- build another iconv state that translates input encoding into input
encoding (unless that enables a fast-path, which I'm not sure of -
alternative might be some encoding that is the ultimate superset, if
such an encoding exists)
- push first unknown byte into it. if that creates a response already,
discard (as it might be some header sequence) and restart with the same
byte in the 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
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mac OS X - resource fork empty after checkout
Brian May schrieb: - Microsoft has introduced something similar in Windows (Vista?) (for compatibility with Mac OS?). NTFS supports data streams for years and years already. Windows 2000 at least already makes use of them for various purposes, too (and I think NT4 already had them. Simple access method, too: filename.txt:streamname. You can even "hide" programs there: given an executable named readme.txt:foobar, do 'start readme.txt:foobar', but explorer and the likes will only show readme.txt and its main content) - As such Samba needs to be able to support it. Doesn't need to - windows doesn't support streams on FAT, so samba can just pretend to not have streams either. - Apple now consider resource forks obsolete as of Max OS X for compatibility with Unix. Obsolete, but supported. I don't know which of these are true or not, but I have heard it has resulted in heated discussions on the Linux kernel mailing list if Linux should support it or not in order to allow Samba to support it. What Linux does have instead (and right now) are extended attributes - not quite the same thing, but similar. Extended attributes are designed for small pieces of information, but resource forks can potentially be very large. Given the right filesystem, EAs can be arbitrarily sized - it's more of a limitation of the filesystem than the API. As for APIs: the POSIX version of EA support never left draft state as far as I know (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 to query that directory. patrick georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] iconv diffs [Was: Why is utf8...]
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/mailman/listinfo/monotone-devel
