Re: [Monotone-devel] [PATCH] mtn commit without -b and mtn branch
> Nathaniel Smith wrote: >> chkeypass, genkey: These are real commands, but they could sure have >> better names. For chkeypass, perhaps 'passphrase' (cf. passwd(1))? I've made this change on mainline. >> Suggestion: teach the command parsing code to simply replace all >> underscores with hyphens when it is figuring out the names of >> commands :-). (They have to stay underscores internally because >> they turn into C++ symbol names, but it's easy to munge the string >> on its way into the command line parsing tables.) Also, I've pushed nvm.experiment.commands-with-dashes that does this. There's a couple of things to note though. 1. It's endlessly debatable as to whether we should do this for the automate commands or not. I chose to do it, but added backward compatibility support for the old command names so that scripts won't break immediately. Presumably we will force the issue some day and bump interface_version when we do. 2. I noticed several automate commands that are either (a) *untested* or (b) *undocumented* or (c) *both* which doesn't strike me as a good thing. So, if anyone has a favorite automate command, perhaps go and check that it appears in monotone.texi and the testsuite. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Help: "mtn: network error: failed to connect: connecttion timed out"
Hi, all, I am a newbie to monotone and am confused with an error.My Linux is Fedora Core 6. My monotone version is 0.32.SeLinux is disabled and iptables is cleared by "iptables -F". I can download OE.mtn by "wget http://openembedded.org/snapshots/OE.mtn.bz2"; (my PC resides behind a proxy and file 'wgetrc' is modified to get the proxy) When I issue: "mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev", I always get following error message: "mtn: network error: failed to connect: connecttion timed out" Anyone could help me? Do I need to tell mtn to use my proxy? How?--Best regards --- 大小单双 机会重重 10分钟就开奖 立即返奖( http://ad4.sina.com.cn/sina/limeng3/mail_zhuiyu/2007/mail_zhuiyu_20070312.html ) === 注册新浪2G免费邮箱（ http://mail.sina.com.cn/chooseMode.html ）___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtnpatch (updated)
On Sun, Mar 11, 2007 at 03:59:12PM +0100, cyril Romain wrote: > Maybe I've just missed the right mtn command reading the documentation, > but as I'm submitting some patches/recipes for OE metadata, I'd like to: > 1. test that my 'mtn diff' patches successfully apply on a up-to-date > metadata tree without any local modifications. > 2. apply some patches to another development tree. > > And this script is "almost" what I'm looking for :) Not sure I understand what exactly you're trying to do here, and would be curious if 'mtn pluck' would work for you, or if not, why not... > "Almost" because it does not takes file/directory drop order into > account, i.e. "mtnpatch.py the.patch | sh" can fail. > For example if mtnpatch dumps: > --- > mtn drop -e packages/quilt/files/install.patch > mtn drop -e packages/quilt/files > --- > And if you run these commands in that order, you get "mtn: misuse: > cannot remove packages/quilt/files/, it is not empty" > > In attachment, an updated version of mtnpatch.py with the following > improvements: > 1. output command are sorted, so that 'mtnpatch.py my_patch.patch | sh' > should now succeed in all cases, hopefully :) It won't. To handle arbitrary add/drop/renames, you have to do somewhat complicated things. The simplest example is: rename a b rename b a (i.e., interchange the two files.) Obviously there's no order you can put those in that will work, you need to move one out of the way to a temporary location first... Other complicated cases involve intermixing different file operations, like add b rename a/foo b/foo drop a add b/foo/baz Here you have to do things in this order in particular, or it won't work. This is all solvable with the right sort of abstraction, I think there are some comments about it in cset.cc, but it requires a trick. The best _documentation_ of the trick is probably this blog post that Aaron Bentley wrote: http://mebentley.blogspot.com/2005/12/tree-transforms-on-posix-filesystems.html I don't know that you care, though :-). -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] cvssync invariant failure
Hi,
I'm not sure if this is interesting to everyone. It's mostly for
Christof Petig I expect. BTW - there is no rush on this any more.
Everyone has moved back to CVS for the moment until I get cvs-sync
running stably for a while. So far my record between glitches is 2
whole days :).
I'm using the cvssync.refactor branch to sync to a medium sized
CVS repository. Saturday morning was the latest hiccup. One of the
cvs users committed a file and then committed it again saying
something about kde locks. CVS itself has no problems checking out
or updating. But, when I try cvs pull with mtn_cvs, I get the
"Inconsistency" message on line 450 of mtn_cvs/cvs_sync.cc and the
invariant on the next line fails. I'm trying to fix things, am a
little out of my depth, and was wondering if anyone has any ideas...
Interestingly, I can pull a fresh mtn repository from cvs
repository. It is only when I try to update my older mtn repository
that I get the problem. I tried various hacks like pulling a new
repos and then syncing that with the old one to try to preserve
history. I didn't think it would work well, and it didn't. There is
something in the old repos that when synced with the freshly-pulled
repository causes it to stop updating with the same problem.
So I've been debugging the underlying problem, but I don't really
understand this yet. I feel like a medieval doctor applying leeches.
The s->cvs_version string on line 450 of mtn_cvs/cvs_sync.cc is
empty, which is weird. That function is called from cvs_sync.cc:
1523, and that function has a "#warning FIXME: changed files" at the
top. Is this going to be related?
If I add a check, if (s->cvs_version.empty()) W(F("s-
>cvs_version.empty()")); at line 1506 then it fires a while before
the "Inconsistency". I don't yet understand why that version is
empty, and chasing that back for a while didn't seem to lead me
anywhere.
I then tried simply removing the invariant that was failing
(drains a little more blood from the patient). This continued and
completed, but at the end dumped out this:
mtn_cvs: warning: blocking attempt to certify an empty CVS revision
of 'CMakeLists.txt'
mtn_cvs: warning: (this is normal for a cvs_takeover of a locally
modified tree)
mtn_cvs: warning: CMakeLists.txt
f47402df16421a331af4c7f5535a175f4b200ef5
mtn_cvs: warning: DartConfig.cmake
5ba1b26cc16d6042ddfd5e8e9ee53ede532ca687
mtn_cvs: warning: README bef4771f00b278b8a5fb5a0c3ce4140fea21890c
[snip ~10 more lines of stuff]
This doesn't fill me with joy. If I update again then I get the "s-
>cvs_version.empty()" warning, but not the "Inconsistency" message.
I also then get "Modules do not match: 'dgc-orca' != ''" which I
didn't get before.
I have copies of the CVS repos, the mtn database that cannot up
without breaking (I have it before the update, so I can re-run the
update easily and reproduce the problem). I'm not sure about the
license on all the files in the repo - so it would be best if I don't
send it to anyone right now, but I can chase that down if people
really want to try.
Be well,
Will :-}
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Translations revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathaniel Smith wrote: > But how does it go about updating the .pot file from the sources, > i.e., finding newly added strings to translate? That's the question > here. It does not ;-) I usually call the make target myself. Lapo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJF9Ij9AAoJELBiMTth2oCDNfkP/AlYbubed9PB5aBJ+/bfV69v ukKWDiEVhLxU64ptBBJT463/5SA7TfncQhTCDHsrwMQg51GJNdgx/4hd3vXHtHbR HevyMtLWVyfdp/W3pfh2691N/JhaS876XLkwJeuVzyjuoVak91e4m9gdGjpSsRf0 gqIi03sRFbbZNzmmOit+qOW0yRwOgp98Y9CkLPx1gpUThFtGCDA33ZEX8HOddu+a RGxMjdh0KhmYqRju1q8CfPoX8+3SUn66ZfQWgWvoiSYz6U2FyAQ4p2Rnl9twjmnc 5XH+UjNod0cJRwhs3x6WgYCxmQlJ6ylPOkkaGU+FeIu8IPwh50SEPqHrgTQw2uv0 3sDPlDGNal0r81UQ2msx7z5Il+/YGF6qTDbEJsrVFGkpMc8wftQwOhdf4F3tKTRt 2MEc9HAbjkKN7QbGAeWTcWlT6mV3w42FxnDPbhm+GvfWjMNoEO8DLvKQPNAxOobg xwiezaTeJg3v9LIxnfSxZP7epHbgOcA/MOFqJX6xq24wMGjc9PJudS997RCeZ3Zq u+RvRliv8D/gxXhl/6dbjMNV/TXvNJJq19SFyYqq9N1fGeDMHYqOJNPgsGUBjrLW izWoYefElI9Rrow2OUtr9+7Othm9i0E/cxdTMEINJ9faHsCaU6HhZH/azvR+jB7w ezNK6zVgwRLDu+cx+lAJ =VB15 -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Translations revisited
On Sun, Mar 11, 2007 at 12:43:11PM +0100, Lapo Luchini wrote: > Nathaniel Smith wrote: > > We don't run intltool, it's part of a translator tool suite. I guess > > I don't know for sure if any of our translators use it now, but at > > least one did at some point. > > Personally I only use (and suggest strongly!) http://poedit.sf.net/ > which is capable to import .pot file, to automatically "fuzzy translate" > similiar string, has a "translation memory" (which can be fed with all > the .po/.mo found in the system) to help find fuzzy translation, and is > overall easy to use and nice. But how does it go about updating the .pot file from the sources, i.e., finding newly added strings to translate? That's the question here. -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: mtnpatch (updated)
Justin Patrin wrote:
Just thought I'd let everyone know that I just cherrypicked my first
revision with mtnpatch.py. I made some efl/e17 updates to .dev and
edited one file, made a diff, and applied the diff to .oz354x with
mtnpatch.py. It worked like a charm.
For those that missed it, I have checked in mtnpatch.py into
org.openembedded.dev in contrib/. I have also switch to using a regex
instead of split() so that whitespace in filenames should be correctly
taken care of.
The script is used like this:
mtn diff -r ParentRev -r RevToCherryPick > file.patch
cd /branch/to/cherrypick/to
contrib/mtnpatch.py file.patch
Look at the output to make sure it's sane
contrib/mtnpatch.py file.patch | sh
mtn ci
Maybe I've just missed the right mtn command reading the documentation,
but as I'm submitting some patches/recipes for OE metadata, I'd like to:
1. test that my 'mtn diff' patches successfully apply on a up-to-date
metadata tree without any local modifications.
2. apply some patches to another development tree.
And this script is "almost" what I'm looking for :)
"Almost" because it does not takes file/directory drop order into
account, i.e. "mtnpatch.py the.patch | sh" can fail.
For example if mtnpatch dumps:
---
mtn drop -e packages/quilt/files/install.patch
mtn drop -e packages/quilt/files
---
And if you run these commands in that order, you get "mtn: misuse:
cannot remove packages/quilt/files/, it is not empty"
In attachment, an updated version of mtnpatch.py with the following
improvements:
1. output command are sorted, so that 'mtnpatch.py my_patch.patch | sh'
should now succeed in all cases, hopefully :)
2. help (-h, --help) option added, and usage message is printed on misuse
3. reverse mode (-R option) can be also set with --reverse
4. the reverse option is used to unapply the patch. The dropped files
are reverted (not added), but maybe it is not what you, Justin, wanted
to do with -R ?
Best regards,
cyril
#!/usr/bin/env python
"""
mtnpatch is a patch tool intended to apply 'mtn diff' patch, including the
additional cset operations (e.g. add, drop and rename) listed in mtn diff comments.
mtnpatch does not actually apply the patch. It only dumps the list of commands to enter
to actually apply the patch.
To apply the patch, use 'mtnpatch.py file.patch | sh'
"""
import sys, os, string, getopt, re
mtncmd = "mtn"
def usage():
print "Usage: mtnpatch.py [options] file.patch"
print "Options:"
print " -h --help display help message"
print " -R --reverse apply patch in reverse"
print "\nTo actually apply the patch, use 'mtnpatch.py file.patch | sh'"
def main(argv = None):
if argv is None:
argv = sys.argv
try:
opts, list = getopt.getopt(sys.argv[1:], 'h:R', ["--help", "--reverse"])
except:
usage()
sys.exit(2)
reverse = False
for o, a in opts:
if o in ("-h", "--help"):
usage()
sys.exit(1)
if o in ("-R", "--reverse"):
reverse = True
if len(list) != 1:
usage()
sys.exit(1)
if os.path.exists(list[0]):
input = open(list[0], 'r')
renameFrom = ""
cmd = ""
addedFiles = []
addedDirs = []
droppedFiles = []
droppedDirs = []
renamedFiles = []
for line in input:
if len(line) > 0:
if line[0] == '#':
matches = re.search("#\s+(\w+)\s+\"(.*)\"", line)
if matches is not None:
cmd = matches.group(1)
fileName = matches.group(2)
isDir = os.path.isdir(fileName)
if cmd == "delete":
if isDir: droppedDirs.append(fileName)
else: droppedFiles.append(fileName)
elif cmd == "add" or cmd == "add_file" or cmd == "add_dir":
if isDir: addedDirs.append(fileName)
else: addedFiles.append(fileName)
elif cmd == "rename":
renameFrom = fileName
elif cmd == "to" and renameFrom != "":
renamedFiles.append((renameFrom, fileName))
renameFrom = ""
else:
cmd = ""
if reverse:
print "patch -R -p0 < %s" % list[0]
for f in addedFiles: print "%s drop -e %s" % (mtncmd, f)
for f in addedDirs: print "%s drop -e %s" % (mtncmd, f)
for fold,fnew in renamedFiles: print "%s rename -e %s %s" % (mtncmd, fnew, fold)
for f in droppedDirs: print "%s revert %s" % (mtncmd, f)
for f in droppedFiles: print "%s revert %s" % (mtncmd, f)
else:
print "patch -p0 < %s" % list[0]
for f in droppedFiles: print "%s drop -e %s" % (mtncmd, f)
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
Nathaniel Smith wrote: > We don't run intltool, it's part of a translator tool suite. I guess > I don't know for sure if any of our translators use it now, but at > least one did at some point. I'm using KBabel, will take a look at poedit. nicolás ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] RoadMap page added to monotone wiki
Hi all! I added a RoadMap page to the monotone wiki where I started to list all projects/tasks which hold us back from releasing 1.0: http://www.venge.net/mtn-wiki/RoadMap Of course this is just a starting point and many of you say "hey, you missed this" or "no, this is not needed for 1.0", so please edit/append this page as you go. Also, if you feel responsible for one or another feature/task in the list, don't hesitate to put your name in there as contact person. I did it for a couple of things where I roughly remembered the responsibilities, but I'm sure I made mistakes there, so feel free to correct those things. Thomas. -- ICQ: 85945241 | SIP: 1-747-027-0392 | http://www.thomaskeller.biz > Guitone, a frontend for monotone: http://guitone.thomaskeller.biz > Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Translations revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathaniel Smith wrote: > We don't run intltool, it's part of a translator tool suite. I guess > I don't know for sure if any of our translators use it now, but at > least one did at some point. Personally I only use (and suggest strongly!) http://poedit.sf.net/ which is capable to import .pot file, to automatically "fuzzy translate" similiar string, has a "translation memory" (which can be fed with all the .po/.mo found in the system) to help find fuzzy translation, and is overall easy to use and nice. Lapo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJF8+tPAAoJELBiMTth2oCDYLUP/1bKij5vJmIKKJN3K0pv/j8m Eku2JBI5RHhRdYej5ZPpwzLY0mbVjg+Cw7d3XGTYyiEVzkHalf6ztK5KNPFdFjs0 G28q/elRrKqfFeQaYbpy+Ajoel7dDDpOmQzqkT1EgbAlaNP092PdHWS3kCpBNTai Q8cL0PSjds9TtsnouYJuaRw/ziKWBjtKPbDu2zP5vxW21Ls3bF51FwasDyQD1gPQ uNy6PDRKIMAkjqV1e8IDWg3meHxXBocVM3uoHwwy8RWe6tAJlGS55vv78VEmYH4y 4JS21FN0FG5qy1ylemF6ix3hAHeC7CAdRE6U+OIBz+J6bZm3xu+zCgnRZeQz2nda 01a9D5TUoRzAA+ZnIR06lUFcqo6vgKFemexDdeAc8dMCe0LOjQCF/p4lB54WvIU1 E86aF0TjP4IHYH/hYaFPuI/toH9yvRv32bDiYWOIsna0Np3F2MfFnS9aHwhrrfCe Sn4KUQKZEKNmIwpth5XrSy/6P+qOIYpb/Vl3FgRwQwta5oiJnTudXxU89ppC8MO+ aOVSrnSZR7H0uiquBaRR5cQrXScwBSZKO6TF/1/UtogGMyMZ7l95+aUDWM5DOsot rIAAfpOiSeX6Yr7oN5/yEQcR2sKBd+mIFszpn4ItMxr5Sh++uMmXrKfATjfM66FY 0moPoUsiToUvTnlhvJCQ =hXLS -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Translations revisited
On Sat, Mar 10, 2007 at 09:48:33PM -0800, Zack Weinberg wrote: > Hum, does intltool really do anything for us? Why not just use > xgettext directly, with the existing list of source files in the > Makefile? (Killing off POTFILES.in as well, yes.) We don't run intltool, it's part of a translator tool suite. I guess I don't know for sure if any of our translators use it now, but at least one did at some point. -- Nathaniel -- "But suppose I am not willing to claim that. For in fact pianos are heavy, and very few persons can carry a piano all by themselves." ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
