Re: [Monotone-devel] improving show_conflicts
Derek Scherger <[EMAIL PROTECTED]> writes: > Stephen Leake wrote: >> If I ultimately want to run merge successfully, I want show_conflicts >> to do exactly what merge would do. > > Note that merge will merge N heads in N-1 steps 2 heads at a time, > without stopping. Ah. I had not realized that. > I'm not sure how helpful show conflicts output would be in cases > where N > 2. Hmm. Since the merges are done 2 heads at a time, the conflict resolution is the same. So it should still be useful. But I will have to construct a test. Hmm. I'll have to see how merge does this. If it picks 2 heads, then outputs conflicts for that merge, then stops, we won't get _all_ conflicts. But that will allow the first merge to succeed, and we can keep iterating until all heads are merged. >> But if I ultimately want to run update succesfully, I want >> show_conflicts to do exactly what update would do. >> How about 'show_conflicts --merge' and 'show_conflicts --update', in >> addition to the current 'show_conflicts rev rev'? > > Alternatively, update --dry-run and merge --dry-run (or --pretend or > --test or whatever) Given the behavior of merge for N > 2, I think this makes much more sense. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] improving show_conflicts
Stephen Leake wrote: If I ultimately want to run merge successfully, I want show_conflicts to do exactly what merge would do. Note that merge will merge N heads in N-1 steps 2 heads at a time, without stopping. I'm not sure how helpful show conflicts output would be in cases where N > 2. But if I ultimately want to run update succesfully, I want show_conflicts to do exactly what update would do. How about 'show_conflicts --merge' and 'show_conflicts --update', in addition to the current 'show_conflicts rev rev'? Alternatively, update --dry-run and merge --dry-run (or --pretend or --test or whatever) Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: ViewMTN multi-db
Thanks, Grahame! Now that I know nagging works, I'll have to figure out
whom to badger thrice a week to have someone fix the db locking, integrate
multi-db netsync (usher/whatnot) with a sensible mtn: url schema, and
whatever else I've forgotten I can't possibly live without! ;-)
I had been imagining the option of:
dbfiles = lambda prefix: ...
for dynamically looking up a prefix in some other table, filesystem, etc.
But that approach does not mesh so well with the nice db selector page,
a feature I was not expecting to have. Nice!
What happens if I don't set a defaultdb? What I'd really like is for the
top-level url to just get to the 'Change DB' page (with slightly different
titling and text for no db currently selected). Really swift would be a
configurable inserted chunk of html for that page, so that could just be
the top-level page of a hosting site with some random local content above
the db selection list.
Can the description strings contain random html?
What I'm now toying with is:
import os.path
import glob
def _flatten(l):
return reduce(lambda a, b: a + b, l)
def _dbfile_tuple(file):
dir = os.path.dirname(file)
name = os.path.basename(dir)
description = None
try:
description = open(os.path.join(dir, 'description')).read()
except IOError:
pass
return (name, file, description)
dbfiles = _flatten(map(_dbfile_tuple, glob.glob('/srv/mtn/*/db.mtn')])
I don't really know Python, so perhaps I missed something obvious. But
note how the flattening is necessary because you want a single tuple of
several triples, instead of a sequence of sequences of some sort. It would
seem more in keeping with e.g. config.graphopts to make it:
dbfiles = ({'name' : 'foo', 'description' : 'bar',
'dbfile' : '/srv/mtn/foo/db.mtn'},
{'name' : 'quux, 'description' : 'yowza,
'dbfile' : '/srv/mtn/quux/db.mtn'})
Or at least simpler all round to make it:
dbfiles = [('foo', '/.../db.mtn', 'bar') ('quux', '/.../db.mtn', 'xx')]
But I did conquer it for a more complex case in about 10 minutes without
knowing Python, so it clearly doesn't much matter.
This was the last piece preventing me from figuring out how I wanted to do
things in Fedora packaging to make a viewmtn server setup work more or less
out of the box. (As soon as I get that packaged setup working, I can get
it deployed on fedorahosted.org.)
Unfortunately, it's not working for me at all. :-(
The setup I did for Fedora packaging is under Apache with mod_wsgi.
http://people.redhat.com/roland/tmp/ has the setup I did for that.
If you use Fedora you can do 'yum localinstall viewmtn-*.noarch.rpm'
to get mod_wsgi and everything else you need for a test install.
This was working before with 0.09/0.08, though I sure never really
understood mod_wsgi or web.py when I got it working.
Now I always get this:
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] Traceback (most recent
call last):
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] File
"/usr/lib/python2.5/site-packages/viewmtn/web/webapi.py", line 304, in wsgifunc
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] result = func()
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] File
"/usr/lib/python2.5/site-packages/viewmtn/web/request.py", line 131, in
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] func = lambda:
handle(inp, fvars)
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] File
"/usr/lib/python2.5/site-packages/viewmtn/web/request.py", line 22, in handle
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] for url, ofno in
utils.group(mapping, 2):
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] File
"/usr/lib/python2.5/site-packages/viewmtn/web/utils.py", line 325, in group
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] seq = iter(seq)
[Wed Feb 20 19:16:25 2008] [error] [client 127.0.0.1] TypeError: 'module'
object is not iterable
The mod_wsgi glue magic in the rpm is via this .../viewmtn/__init__.py file:
from viewmtn import *
application = web.wsgifunc(web.webpyfunc(urls, globals()))
Maybe that idiom has changed?
Thanks,
Roland
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] ViewMTN multi-db
Hi guys I've spent the last few nights adding multiple-database support to ViewMTN. It seems to work, so I've installed the multidb version on viewmtn.angrygoats.net. i'd really appreciate it if people could take a look and try to break it. There may be bugs in any of the page handlers; I've tried to be thorough, but it's quite a big program to test! Even clicking through randomly to try and get an exception would be good :-) All the old URLs work, but you'll notice that most of the links on that install now have a '/all/' prefix. ViewMTN in multi-db mode adds a database name at the beginning of each URL to specify the database. If that prefix is not present, it uses a default (which in the case of viewmtn.angrygoats.net is to behave exactly as it did before.) There are separate pools of mtn automate processes for each DB. If you follow the change DB link at the top right, you can switch to a little DB I've created with just the ViewMTN source in it. You'll now have a '/viewmtn/' prefix on your URLs. It seems to work for me, any feedback would be great. I'll probably do a release tomorrow if no major problems are reported. The code for this is in branch net.angrygoats.viewmtn, pull from monotone.ucc.gu.uwa.edu.au. I've gone through and tidied up the code - it has been broken out into more source files, and should be a lot easier to follow now. Cheers! Grahame ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] viewmtn urls
Hi Brian That should have worked, so I've fixed it. This format of URL now works: http://viewmtn.angrygoats.net/branch/head/filechanges/net.angrygoats.viewmtn/README Hopefully that's what you wanted! The fix is in net.angrygoats.viewmtn on monotone.ucc.gu.uwa.edu.au, but there's a bunch of other changes in there too (about to send an email to the list about them), so be warned! Cheers Grahame On 17/02/2008, Brian May <[EMAIL PROTECTED]> wrote: > Hello, > > If I want to get the package for the latest version of a file, I can > go to the following url > > http://server.com/viewmtn/branch/head/file/[[branch]]/[[file]] > > If I want to get the latest history of this file, is there a similar > URL I can go to? > > I can see: > > http://server.com/viewmtn/revision/filechanges/[[version]]/[[file]] > > But I don't want to have to hard code the version. However, hard > coding the branch, I think is OK. > > (required to get the ikiwiki history link working correctly) > > Thanks > > -- > Brian May <[EMAIL PROTECTED]> > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel > ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] improving show_conflicts
Derek Scherger <[EMAIL PROTECTED]> writes: > Stephen Leake wrote: >> It turns out there is such a command already; show_conflicts. >> However, I'd like it to default to the two current heads as merge >> does. > > I thought the other day that it would be nice if show_conflicts could > also take one or two --revision options and work something like diff. > i.e. show_conflicts -r xxx would show the conflicts if you were to > update the current workspace to the specified rev. Ok. > show_conflicts -r xxx -r yyy would show the conflicts between the > two specified revisions. As it currently does. > At the time I was thinking that without any -r options it would show > the conflicts between the current workspace and the revision that > update would choose as its target. Ok. > This kinda collides with defaulting to the two current heads, but > I'm not so sure that makes sense anyway, as there might be 3 or more > current heads, Yes. > or one, etc. I suppose it could take the first two heads that merge > would work with first. If I ultimately want to run merge successfully, I want show_conflicts to do exactly what merge would do. But if I ultimately want to run update succesfully, I want show_conflicts to do exactly what update would do. How about 'show_conflicts --merge' and 'show_conflicts --update', in addition to the current 'show_conflicts rev rev'? > Note that show_conflicts will list content conflicts for any files > that have changed on both sides, regardless of whether they would > merge cleanly or not. It's only looking at the content hash. Ok. The GUI could then offer to run the mtn internal merger on content conflicts. So that needs an automate interface as well. For now, the GUI can just run an external merger; Emacs ediff is fine. The user may want to preview the changes anyway. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision [was --non-interactive ... ]
On Feb 20, 2008 10:12 AM, Thomas Keller <[EMAIL PROTECTED]> wrote: > > Looking at differences: > > 1. Your version fails if there are no changes in workspace. Dunno if > > it's good or not. (after few minutes of thinking it's rather good). > > Given the fact that you can't do anything with the revision it spits out > in this case and that all the "new" information you get there is a bogus > new_manifest ID and the format version of the revision format (the > old_revision can easily be queried already by get_base_revision_id), I > think it would be indeed a good idea to put that check in there. I'll > leave that to you (+ the obligatory test), so we don't do that again > both - I have to return to my main work some time today anyways ;) Sorry to interrupt, but are you talking about "automate get_current_revision_id" ? If it is, I make use of it in a script and count on the fact that is returns the same as "get_base_revision_id" if there are no changes on the workspace. If it's not, forget this... Regards, ~Nuno Lucas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision [was --non-interactive ... ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zbigniew Zagórski schrieb: > Hmm, sorry for mess i didn't know about that branch. Lot of > interesting things are hidden there in nvm Yeah, I "digged" it out recently after adding it to the "BranchStatuses" wiki page. I forgot about it myself as well, originally I pretty much had the same drive to implement it like you have now (and I still have somehow, but I was distracted with other things for guitone). Nevertheless nice, the next version of guitone allows restricted commits then ;) > Looking at differences: > 1. Your version fails if there are no changes in workspace. Dunno if > it's good or not. (after few minutes of thinking it's rather good). Given the fact that you can't do anything with the revision it spits out in this case and that all the "new" information you get there is a bogus new_manifest ID and the format version of the revision format (the old_revision can easily be queried already by get_base_revision_id), I think it would be indeed a good idea to put that check in there. I'll leave that to you (+ the obligatory test), so we don't do that again both - I have to return to my main work some time today anyways ;) > 2. I think it's reasonable to limit functionality of get_revision to > give only revisions form database. (automate_get_revision test needs > to be updated) Yep, already did that. > 3. Code is almost the same ... looks like we copy-pasted from same source ;) Yay, the copy'n'paste monster! Thomas. - -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHu/0Saf7NlBYNEJIRAgBQAKCclwQQtzHrOSKy3HPjV71tDorgmgCfaIcq cLtoUc6nlHZGrSggFfBxLIY= =bElc -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision [was --non-interactive ... ]
2008/2/20, Thomas Keller <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Zbigniew Zagórski schrieb: > > 31-01-08, Zbigniew Zagórski <[EMAIL PROTECTED]> napisał(a): > >> Thomas Keller wrote: > >> ... > >> > > >> > On a related note, if you think of doing commits over automate like > >> > I currently do, what is really _lacking_ in automate is a way to > >> let > mtn > >> > return a valid restricted revision for a given set of paths (i.e. I > >> > currently just feed put_revision with the complete output of > >> > get_revision). One could of course do the node restriction logic in > >> > the client (f.e. for renames), but this is very ugly. > >> > >> How about adding: > >> > >> automate get_current_revision [PATHS...] > >> > >> Which will return current workspace revision restricted with PATHS. > >> Now when automate commands can accept options it will be possible to > >> add --depth and --exclude options also. > > > > Hi, > > > > I've commited f6cb000f1bbcf35e6458c5e62e10ecef02021752 with > > implementation of this command. Please review if worried about quality > > ;) (tests/doc/NEWS). > > > > Best regards, > > Heh... I totally forgot about that thread, and that there is already an > implementation for get_current_revision sitting in > nvm.automate_current_revision (for quite some time) - but this is not a > problem. I'll review your version and we'll take just that. If > everything is ok, I'll suspend the old branch. Hmm, sorry for mess i didn't know about that branch. Lot of interesting things are hidden there in nvm Looking at differences: 1. Your version fails if there are no changes in workspace. Dunno if it's good or not. (after few minutes of thinking it's rather good). 2. I think it's reasonable to limit functionality of get_revision to give only revisions form database. (automate_get_revision test needs to be updated) 3. Code is almost the same ... looks like we copy-pasted from same source ;) 4. I'm curious if your code will pass my unittest... I think that if we merge both revs the result will be interesting and usable. I can do it this evening ... -- Zbigniew Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Keller schrieb: > Zbigniew Zagórski schrieb: >> I've commited f6cb000f1bbcf35e6458c5e62e10ecef02021752 with >> implementation of this command. Please review if worried about quality >> ;) (tests/doc/NEWS). > >> Best regards, > > Heh... I totally forgot about that thread, and that there is already an > implementation for get_current_revision sitting in > nvm.automate_current_revision (for quite some time) - but this is not a > problem. I'll review your version and we'll take just that. If > everything is ok, I'll suspend the old branch. I improved the wording here and there and also made the REVID argument to get_revision mandatory now (we do not need two commands which essentially do the same under some circumstance ;). Pushed as 938919199a4b4e425eedac1266f8b54799dc2f5f. Thomas. - -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHu/m/af7NlBYNEJIRAq0aAKDOzJymWThS0yDz0b0PYQXFhP9XGwCgobAs /Us7oL10mvr0J5oAeLqG/b8= =qovI -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] restrictions: disabling recursion
In message <[EMAIL PROTECTED]> on Tue, 19 Feb 2008 18:26:23 -0500, "Zack Weinberg" <[EMAIL PROTECTED]> said: zackw> You've run afoul of this, I think: zackw> zackw> // FIXME: this uses depth+1 because the old semantics of depth=0 were zackw> // something like "the current directory and its immediate children". it zackw> // seems somewhat more reasonable here to use depth=0 to mean "exactly zackw> // this directory" and depth=1 to mean "this directory and its immediate zackw> // children" zackw> zackw> The "old" behavior has been preserved in the name of backward zackw> compatibility. I'd have no objection to calling a flag day and zackw> introducing the more sensible semantics you suggest (which are the zackw> same as the ones suggested in the restrictions.cc comments). What do zackw> other people think? I have no problem with that in itself. Perhaps one should consider renaming --depth to something else, so the change becomes more blatant. I don't have any other name in mind right now, but it's something to think of... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] automate get_current_revision [was --non-interactive ... ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zbigniew Zagórski schrieb: > 31-01-08, Zbigniew Zagórski <[EMAIL PROTECTED]> napisał(a): >> Thomas Keller wrote: >> ... >> > >> > On a related note, if you think of doing commits over automate like >> > I currently do, what is really _lacking_ in automate is a way to >> let > mtn >> > return a valid restricted revision for a given set of paths (i.e. I >> > currently just feed put_revision with the complete output of >> > get_revision). One could of course do the node restriction logic in >> > the client (f.e. for renames), but this is very ugly. >> >> How about adding: >> >> automate get_current_revision [PATHS...] >> >> Which will return current workspace revision restricted with PATHS. >> Now when automate commands can accept options it will be possible to >> add --depth and --exclude options also. > > Hi, > > I've commited f6cb000f1bbcf35e6458c5e62e10ecef02021752 with > implementation of this command. Please review if worried about quality > ;) (tests/doc/NEWS). > > Best regards, Heh... I totally forgot about that thread, and that there is already an implementation for get_current_revision sitting in nvm.automate_current_revision (for quite some time) - but this is not a problem. I'll review your version and we'll take just that. If everything is ok, I'll suspend the old branch. Thomas. - -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHu+8aaf7NlBYNEJIRAlnYAJ9XjdyKAFtY2HHHF9aDgOId8F17dQCg5wf7 +kYpogC3yRTV1egjNPtJXS8= =BUGR -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
