2008-06-19T00:11:08 <TheSheep> sheep@ghostwheel:~/dev/moin/moin-1.7$ hg push
2008-06-19T00:11:08 <TheSheep> abort: no suitable response from remote hg!
2008-06-19T00:12:18 <TheSheep> what am I doing wrong?
2008-06-19T00:12:55 <xorAxAx> TheSheep: try ssh only
2008-06-19T00:13:02 <xorAxAx> and see how the response looks like
2008-06-19T00:13:10 <xorAxAx> or find a parameter to let hg dump the response
2008-06-19T00:13:26 <TheSheep> debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
2008-06-19T00:13:30 <TheSheep> debug3: channel 0: close_fds r -1 w -1 e 6 c -1
2008-06-19T00:13:32 <TheSheep> Connection to hg.moinmo.in closed.
2008-06-19T00:13:49 <xorAxAx> thats plain ssh? doesnt look too bug
2008-06-19T00:13:54 <xorAxAx> bad
2008-06-19T00:14:11 <TheSheep> yeah, it seems the problem is in higher layers
2008-06-19T00:15:14 <TheSheep> at least this is reasuuring:
2008-06-19T00:15:15 <TheSheep> debug1: Authentication succeeded (publickey).
2008-06-19T00:15:38 * TheSheep goes to install newer hg
2008-06-19T00:18:42 <TheSheep> same :(
2008-06-19T00:18:53 <TheSheep> ThomasWaldmann: can I send you a bundle?
2008-06-19T00:32:28 <CIA-52> Radomir Dopieralski <moindev@sheep.art.pl> default * 3712:7d77145af210 1.7/MoinMoin/theme/__init__.py: ThemeBase: add a <link> in the <header> for the editor
2008-06-19T00:36:14 <ThomasWaldmann> works :)
2008-06-19T00:37:28 <TheSheep> amazing
2008-06-19T02:30:25 <starshine> hrm, about time I fetch a 1.7 tree :)
2008-06-19T08:12:23 <ThomasWaldmann> moin
2008-06-19T08:31:08 <dreimark> moin
2008-06-19T08:39:23 <dreimark> ThomasWaldmann: I schedule the changes in moin account create, disable and resetpw to 1.7.1 it is not such urgent that it needs to be fixed in 1.7.0
2008-06-19T08:49:04 <ThomasWaldmann> what changes?
2008-06-19T08:54:18 <dreimark> ThomasWaldmann: 18:31 < dreimark> ThomasWaldmann: moin script create should not be able to overwrite a user or to create a user with the same email address
2008-06-19T08:55:24 <dreimark> and following lines from yesterday
2008-06-19T09:22:03 * dreimark fixes the msg bug in add_attachment for 1.6.3
2008-06-19T09:37:59 <CIA-52> Reimar Bauer <rb.proj AT googlemail DOT com> default * 2665:c8bdc6c922e7 1.6/MoinMoin/action/AttachFile.py:
2008-06-19T09:37:59 <CIA-52> AttachFile.add_attachment: bug fix for AttachmentMessageIncorrectOverwriteNotChecked
2008-06-19T09:37:59 <CIA-52> backport of second hunk from moin/1.7/rev/15e5ca7240ab raise AttachmentAlreadyExists
2008-06-19T10:14:44 <xorAxAx> johill: http://www.vidarholen.net/contents/wordcount/graph.png
2008-06-19T10:21:11 <johill> xorAxAx: that's less increase than the number of lines ;)
2008-06-19T10:24:14 <dennda> We conclude that kernel devs get more polite or more relaxed
2008-06-19T10:25:49 <zenhase> moin
2008-06-19T10:28:36 <zenhase> or the code is getting less swear-worthy ;)
2008-06-19T10:34:05 <PawelPacana> moin
2008-06-19T13:25:19 * dennda wonders if he needs to support 2.3
2008-06-19T13:25:32 <dennda> ThomasWaldmann, johill what do you think?
2008-06-19T13:26:36 <ThomasWaldmann> dennda: yes you need
2008-06-19T13:27:54 <dennda> :(
2008-06-19T13:29:36 <ThomasWaldmann> we will require py 2.4 at some time in the future, but see the poll site, there are still some questions open and until there is no decision for py 2.4, the current requirement of 2.3 still applies
2008-06-19T13:29:55 <ThomasWaldmann> s/site/page/ X)
2008-06-19T13:31:12 <dennda> I was just wondering because I thought 1.8 was going to be 2.4 upwards
2008-06-19T13:32:03 <ThomasWaldmann> there are thoughts to do that (see that page), but there is no decision yet
2008-06-19T13:32:50 <johill> what specifically do you need from 2.4?
2008-06-19T13:33:13 <dennda> decorators would be quite nice for instance
2008-06-19T13:33:18 <johill> if it makes things really awkward, I wouldn't want to require 2.3
2008-06-19T13:33:31 <johill> decorators aren't really needed
2008-06-19T13:33:40 <dennda> there's no urgent need (yet) but having them would make baby jesus smile
2008-06-19T13:34:06 <johill> well you can still decorate functions
2008-06-19T13:34:12 <johill> you just need to write it differently
2008-06-19T13:34:17 <johill> def abc(...):
2008-06-19T13:34:18 <johill> ...
2008-06-19T13:34:22 <johill> abc = decorator(abc)
2008-06-19T13:34:24 <dennda> yes but not using the ultra cool syntax :D
2008-06-19T13:34:53 <dennda> anyway, I was just wondering
2008-06-19T13:35:39 <johill> k
2008-06-19T13:36:36 <gizmach> re
2008-06-19T13:40:04 <dennda> johill: I am trying to think about implementing commit on items... How is an Item supposed to know which revision it shall commit to itself? (yes, I know there is only one revno possible, but still: how does the item know which NewRevision object is going to be committed? get_revision cannot work because that only gets revisions that have already been committed)
2008-06-19T14:17:42 <johill> dennda: I figured item.new_revision would store the returned revision object in item._new_revision_for_commit or something
2008-06-19T14:21:55 <dennda> johill: ok, I had the same idea, but what happens if two people create a revision with the same revno and one calls commit? Wouldn't that imply passing the revision you want to be committed to be passed to commit()
2008-06-19T14:23:51 <johill> I don't understand
2008-06-19T14:23:57 <johill> item objects are only proxies
2008-06-19T14:23:58 <dennda> ok, let me rephrase
2008-06-19T14:24:01 <johill> every one gets one
2008-06-19T14:24:15 <dennda> ah yeh forget the question
2008-06-19T14:24:40 <johill> so in fact Item() wants to "assert self._new_revision_object is None" or something in create_revision
2008-06-19T14:25:11 <dennda> so I need to worry about clashing as soone as someone tries to commit a revision with a revno that already exists in the "data storage"
2008-06-19T14:25:39 <dennda> yes, I forgot that you won't have two people using the same Item object to create revision number 1337
2008-06-19T14:26:02 <johill> oh yeah the actual storage has to be checking for stuff like that and guarantee consistency
2008-06-19T14:26:17 <TheSheep> guys, I have a copule of questions
2008-06-19T14:26:52 * dennda is currently listening to a lecture, so expect a few delays :)
2008-06-19T14:27:29 <TheSheep> let me find it...
2008-06-19T14:27:55 <TheSheep> 1. can you call .commit() on an item with no revisions? what would be the result?
2008-06-19T14:27:56 <dennda> lectures topic: concurrency, isn't that great? :)
2008-06-19T14:28:23 <dennda> TheSheep: we havn't defined that, but I guess it should throw an exception NoRevisionToBeCommitted or something
2008-06-19T14:28:23 <TheSheep> 2. can you call .create_revision() on an item several times before calling .commit()?
2008-06-19T14:28:28 <johill> TheSheep: umm, you're not supposed to, why? it probably wants to raise some exception then
2008-06-19T14:28:32 <johill> (that was 1.)
2008-06-19T14:28:51 <johill> TheSheep: 2.: no, we just discussed that, it's a use case we don't need and adding multiple revisions consistently is hard
2008-06-19T14:29:25 <TheSheep> so, the new revision object can be just moved into item itself?
2008-06-19T14:29:45 <johill> moved?
2008-06-19T14:30:13 <TheSheep> like, you can store the data that would normally go to the revision object in the item object as well
2008-06-19T14:30:24 <TheSheep> like the handle to an open temp file
2008-06-19T14:30:29 <TheSheep> or such
2008-06-19T14:31:13 <johill> yeah it could, but the API mandates you have a revision object to manipulate
2008-06-19T14:31:31 <TheSheep> which can be just a proxy to the item :)
2008-06-19T14:31:53 <TheSheep> ok, thanks, that explains a lot
2008-06-19T14:32:14 <TheSheep> 3. can you call create_revision, commit, create_revision, commit on the same item multiple times?
2008-06-19T14:32:24 <johill> yeah I think that should be fine
2008-06-19T14:33:46 <TheSheep> 4. the only difference between get_item and create_item is that they raise exceptions in different situations, right?
2008-06-19T14:33:55 <dennda> oh no
2008-06-19T14:34:01 <dennda> @4
2008-06-19T14:34:01 <moinBot> dennda: Error: "4" is not a valid command.
2008-06-19T14:34:24 <dennda> create_item creates a new item on the backend and returns it (and stores it in the backends data storage)
2008-06-19T14:34:33 <dennda> and get_item gets an existing item from the backends data storage
2008-06-19T14:34:36 <TheSheep> dennda: so create_item commits?
2008-06-19T14:34:40 <dennda> no
2008-06-19T14:34:50 <dennda> it gives you an item that can create revisions which then can be committed
2008-06-19T14:35:10 <TheSheep> so does get_item
2008-06-19T14:35:25 <TheSheep> let me put it differently
2008-06-19T14:36:04 <TheSheep> after calling create_item("foo"), but before creating any revisions and commiting them, what should be the value of has_item("foo")?
2008-06-19T14:36:22 <dennda> True
2008-06-19T14:36:27 <TheSheep> damn
2008-06-19T14:36:31 <TheSheep> I was afraid of it
2008-06-19T14:36:35 <dennda> get_item("foo") however gives you the item
2008-06-19T14:36:42 <dennda> (that you just created)
2008-06-19T14:37:00 <TheSheep> so now we need to find a way of storing revision-less items in mercurial :(
2008-06-19T14:37:20 <dennda> well, create an initial revision
2008-06-19T14:37:24 <dennda> with no data
2008-06-19T14:37:33 <TheSheep> then the revision numbers are wrong
2008-06-19T14:37:48 <TheSheep> especially if several backends do that at the same time
2008-06-19T14:37:56 <TheSheep> and merge the conflict
2008-06-19T14:39:20 <TheSheep> I guess we will just have to keep an additional file with a list of item names that exist but have no revision
2008-06-19T14:39:39 <johill> TheSheep: you need to find ways to store revision-less items anyway because metadata can be changed, and say user storage uses no revisions
2008-06-19T14:39:50 <johill> TheSheep: hence you can't map item revisions exactly to hg revisions anyway
2008-06-19T14:40:45 <TheSheep> johill: arent metadata and data revisions synchronised?
2008-06-19T14:42:05 <TheSheep> johill: how do you tell which metadata revision belongs to which data revision then?
2008-06-19T14:42:45 <dennda> he is talking of item metadata
2008-06-19T14:42:53 <dennda> you can have an item with metadata that has no revisions
2008-06-19T14:42:55 <dennda> (e.g. users)
2008-06-19T14:43:09 <TheSheep> that's a different backend, right?
2008-06-19T14:43:41 <dennda> hm?
2008-06-19T14:44:10 <johill> TheSheep: well, it's a different backend instance
2008-06-19T14:44:14 <johill> but it is the same api etc
2008-06-19T14:44:22 <dennda> backend.create_item("user_johill")
2008-06-19T14:44:26 <dennda> x = backend.create_item("user_johill")
2008-06-19T14:44:35 <dennda> x["password"] = "ultrasafe"
2008-06-19T14:44:52 <johill> you forgot x.lock_metadata() or something
2008-06-19T14:44:57 <dennda> yes
2008-06-19T14:44:59 <dennda> simplified
2008-06-19T14:45:33 <johill> well it should be
2008-06-19T14:45:37 <johill> x.begin_metadata_update()
2008-06-19T14:45:40 <johill> x['...'] = ...
2008-06-19T14:45:44 <johill> x.commit_metadata_update()
2008-06-19T14:46:00 <TheSheep> so the data and metadata are kept in the same storage backend after all?
2008-06-19T14:46:13 <johill> since metadata is only written on the unlock or something
2008-06-19T14:46:23 <johill> TheSheep: well, they are kept in the same storage API stuff
2008-06-19T14:46:32 <johill> TheSheep: but they are kept in different instances of backends
2008-06-19T14:46:34 <johill> so you'd have
2008-06-19T14:46:46 <johill> cfg.user_storage = HGBackend(/mywiki/users)
2008-06-19T14:46:54 <johill> cfg.page_storage = HGBackend(/mywiki/pages)
2008-06-19T14:47:42 <TheSheep> and cfg.page_storage keeps both page data and metadata?
2008-06-19T14:49:02 <dennda> yes
2008-06-19T14:49:02 <gizmach> ThomasWaldmann, dreimark : http://paste.pocoo.org/show/73606/ this is how I got checked of which group is usera member of, it is just to try if it works and I asked now on mailing lists how to make it configurable
2008-06-19T14:49:09 <gizmach> just to know users uid
2008-06-19T14:49:17 <TheSheep> and they both change independently, so you can have several revisions of metdata with the same revision of data, ad vice versa?
2008-06-19T14:49:29 <TheSheep> how do you tell which one you want?
2008-06-19T14:49:30 <johill> TheSheep: revision or item metadata?
2008-06-19T14:49:45 <gizmach> and that it has a word member*/*Member* in a record
2008-06-19T14:50:03 <johill> TheSheep: each revision has metadata which cannot be changed once the revision exists, but each _item_ also has metadata (used for page locking for example) and that can change
2008-06-19T14:50:22 <johill> and you probably have to revision item metadata for the hg backend under the hood
2008-06-19T14:51:55 <TheSheep> now, suppose I revert an item from revision 4 to revision 2, this creates revision 5, but revision 2 has had 3 different revisions of item metadata, which revision of item metadata should the item have after revert?
2008-06-19T14:53:12 <johill> that's the wrong question to ask
2008-06-19T14:53:20 <johill> conceptually, item metadata is _not_ revisioned
2008-06-19T14:53:30 <TheSheep> if I can't ask this question, how am I supposed to imnplement reverting?
2008-06-19T14:53:42 <TheSheep> wait, you siad it is
2008-06-19T14:53:44 <johill> you don't implement reverting anyway
2008-06-19T14:53:45 <xorAxAx> you are not supposed to do it :)
2008-06-19T14:53:48 <johill> moin does
2008-06-19T14:53:52 <xorAxAx> pawel does
2008-06-19T14:53:59 <xorAxAx> :)
2008-06-19T14:54:08 <johill> no we don't revert on hg level
2008-06-19T14:54:13 <xorAxAx> yes, wrong level, TheSheep - thats a high level operation
2008-06-19T14:54:21 <johill> we look at the old data and store it in a new revision
2008-06-19T14:54:36 <TheSheep> johill: but what happens with teh metadata?
2008-06-19T14:54:48 <johill> it's not touched
2008-06-19T14:55:00 <TheSheep> if they have completely independent revisions, it's madness
2008-06-19T14:55:01 <johill> well, it's actually checked that nobody is editing while you try to revert
2008-06-19T14:55:04 <ThomasWaldmann> gizmach: that test maybe works, but the query is no good
2008-06-19T14:55:10 <xorAxAx> TheSheep: ?
2008-06-19T14:55:17 <johill> TheSheep: conceptually, item metadata *has no revisions*
2008-06-19T14:55:32 <johill> none at all, nada, it's "just there"
2008-06-19T14:55:47 <xorAxAx> yes, item metadata is the set of metadata keys that should not be revisioned
2008-06-19T14:56:03 <johill> [yes, for hg that is impossible, so you need to store it in a separate file and actually commit it anyway]
2008-06-19T14:56:09 <TheSheep> ok, so I can just have a 'meta' directory outside the repository and keep it there
2008-06-19T14:56:21 <johill> not really
2008-06-19T14:56:26 <johill> that would kill most benefits of using hg
2008-06-19T14:56:29 <TheSheep> this also lets me check which items "exist" even when they don't have any revisions commited
2008-06-19T14:56:31 <johill> because you couldn't clone a wiki any more
2008-06-19T14:56:41 <xorAxAx> johill: well, p
2008-06-19T14:56:51 <johill> p?
2008-06-19T14:56:55 <xorAxAx> suppose there is a subset of keys that are not integral for a wiki
2008-06-19T14:57:05 <xorAxAx> do we have a list of item metadata keys?
2008-06-19T14:57:14 <TheSheep> you don't relaly want to clone locks, do you?
2008-06-19T14:57:22 <johill> right now the list is just four keys, the edit-lock stuff
2008-06-19T14:57:32 <xorAxAx> wikisync as well
2008-06-19T14:57:35 <johill> (owner, time and something)
2008-06-19T14:57:37 <johill> right
2008-06-19T14:57:45 <xorAxAx> thats nothing you want to clone
2008-06-19T14:57:46 <johill> ok but otoh users are also stored as item metadata
2008-06-19T14:57:59 <johill> and that you may want to clone for backups
2008-06-19T14:58:20 <xorAxAx> well, thinking about use cases, backup should be done differently
2008-06-19T14:58:33 <xorAxAx> i think an hg backend should enable more user centric use cases :)
2008-06-19T14:58:41 <johill> well, yeah
2008-06-19T14:59:01 <TheSheep> maybe user store should be implemented differently?
2008-06-19T14:59:06 <TheSheep> I mean for hg only
2008-06-19T14:59:09 <xorAxAx> nevertheless it needs to be decided whether there are item metadata keys that would need to be transferred remotely
2008-06-19T14:59:11 <TheSheep> not in the api
2008-06-19T14:59:12 <johill> it can't really
2008-06-19T14:59:16 <xorAxAx> i guess that depends on the use cases
2008-06-19T14:59:22 <johill> because the API doesn't really tell you what you're storing
2008-06-19T14:59:30 <xorAxAx> umm
2008-06-19T14:59:44 <xorAxAx> you dont want to store users with the hg backend anyway
2008-06-19T14:59:48 <TheSheep> when you're syncing wikis, you don't always want to synch users, do you?
2008-06-19T14:59:52 <xorAxAx> not sure why anyone would want to do it
2008-06-19T14:59:52 <johill> well yeah if you do that that's a weird config
2008-06-19T14:59:58 <TheSheep> xorAxAx: for cloning
2008-06-19T15:00:01 <xorAxAx> so you just choose a different backend
2008-06-19T15:00:08 <xorAxAx> TheSheep: why do you want to clone users?
2008-06-19T15:00:08 <johill> it's not stored in the same instance anyway
2008-06-19T15:00:12 <xorAxAx> thats sensitive internal data
2008-06-19T15:00:19 <xorAxAx> passwords etc.
2008-06-19T15:00:22 <TheSheep> xorAxAx: biuld an army and take over the wolrd, of course!
2008-06-19T15:00:48 <johill> so yeah I'm ok with the hg backend storing metadata 'out of band' so to speak and simply being of no real use for user storage
2008-06-19T15:00:52 <xorAxAx> that would have worked 75 years ago
2008-06-19T15:01:09 <xorAxAx> johill: as i said, nobody really wants to do that
2008-06-19T15:01:18 <johill> yeah probably not
2008-06-19T15:01:23 <xorAxAx> johill: pushing passwords into an hg repo that is supposed to contain wiki data
2008-06-19T15:01:35 <johill> xorAxAx: it's never the same repo either way
2008-06-19T15:01:41 <xorAxAx> well, there is a tight coupling of wiki home page and sensistive data here
2008-06-19T15:01:42 <TheSheep> johill: thanks for the chat, now I have some thinking to do, I will probably come back with more questions :)
2008-06-19T15:01:49 <xorAxAx> which isnt the nicest way to go :)
2008-06-19T15:01:59 <johill> xorAxAx: huh? how does the wiki homepage play in there?
2008-06-19T15:02:07 <johill> I think you're confused
2008-06-19T15:02:11 <johill> ;)
2008-06-19T15:02:36 <TheSheep> xorAxAx: you could store the homepages in a different wiki...
2008-06-19T15:02:37 <xorAxAx> johill: users have a username whichis an item name of an item that has e.g. a password as metadata but also refers to the homepage itself
2008-06-19T15:02:41 <xorAxAx> johill: no?
2008-06-19T15:02:45 <johill> no
2008-06-19T15:02:51 <TheSheep> johill: if you don't clone the users, you still clone thier home pages
2008-06-19T15:02:53 <xorAxAx> how does it work?
2008-06-19T15:03:03 <johill> users are in a different storage backend, their item name is the UID
2008-06-19T15:03:08 <xorAxAx> ok
2008-06-19T15:03:21 <xorAxAx> ok, better. so even less reasons to use the hg backend for that
2008-06-19T15:03:32 <johill> they aren't linked to their homepage in any way except the convention that the useritem['name'] == homepagename
2008-06-19T15:03:43 <xorAxAx> like in the old days
2008-06-19T15:03:58 <johill> never changed
2008-06-19T15:04:09 <xorAxAx> yes
2008-06-19T15:04:11 <johill> and I have no intention of doing that, that would be madness
2008-06-19T15:04:20 <johill> (somebody renames your homepage and you can no longer log in??)
2008-06-19T15:04:34 <johill> now
2008-06-19T15:04:41 <johill> an interesting addition would be adding a User: namespace
2008-06-19T15:04:50 <johill> that would, indeed, store the page contents in the user object
2008-06-19T15:05:49 <xorAxAx> ugh :)
2008-06-19T15:06:51 <dennda> please, don't create such a big backlog :D
2008-06-19T15:14:27 <dennda> (didn't want to scare you away, though)
2008-06-19T15:14:45 <johill> xorAxAx: yeah, mostly ugh because it wouldn't allow sub-pages ;)
2008-06-19T15:15:02 <gizmach> ThomasWaldmann: I know the querry is no good, I'm looking for a better one
2008-06-19T15:23:32 <ThomasWaldmann> you already had better ones
2008-06-19T15:24:07 <gizmach> ThomasWaldmann: ok, I don't need to look at the all records that have objectClass, I need only those that have member (some combination of member word in it)
2008-06-19T15:24:10 <ThomasWaldmann> and you also already know not to request attributes you don't need (== only request attributes you need)
2008-06-19T15:24:15 <gizmach> ThomasWaldmann: but onlyfor groups
2008-06-19T15:24:36 <gizmach> yes I changed that I removed objectClass
2008-06-19T15:25:33 <zenhase> uh
2008-06-19T15:25:55 <zenhase> lot's of chat the last 2h
2008-06-19T15:25:59 <ThomasWaldmann> btw, you could also have a look at how other sw does this
2008-06-19T15:26:07 <ThomasWaldmann> e.g. samba has a ldap integration
2008-06-19T15:27:22 <zenhase> regarding the poll for py 2.4
2008-06-19T15:27:40 <zenhase> i realized that the page misses some information, what benefits the requirement would bring
2008-06-19T15:27:47 <gizmach> :) will,
2008-06-19T15:28:10 <zenhase> (i mean @decorator is not that big of an advantage, with-statement in py2.5 would perhaps be)
2008-06-19T15:28:43 <johill> zenhase: one of the big things is that we ship lots of workaround-code for python 2.3
2008-06-19T15:28:44 <zenhase> one of func- or itertools was a 2.4 thing iirc
2008-06-19T15:28:47 <johill> and nobody ever keeps it up-to-date
2008-06-19T15:28:49 <ThomasWaldmann> zenhase: i guess that is known, but feel free to add a section
2008-06-19T15:29:35 <ThomasWaldmann> some more info from the userbase about rhel/centos/sles would be more useful, though
2008-06-19T15:29:59 <xorAxAx> johill: and nobody tests on 2.3
2008-06-19T15:30:09 <xorAxAx> esp. not those who break the 2.3 support
2008-06-19T15:30:34 <johill> yeah that too
2008-06-19T15:30:56 <johill> (I even broke 2.4 support at one point. heh)
2008-06-19T15:59:09 <gizmach> re
2008-06-19T18:21:54 <dreimark> re
2008-06-19T18:57:28 <CIA-52> Florian Krupicka <florian.krupicka@googlemail.com> default * 3687:632696c3c78d 1.8-wsgi-fkrupicka/MoinMoin/ (Page.py auth/http.py session.py): Replaced calls to setHttpHeader
2008-06-19T18:57:30 <CIA-52> Florian Krupicka <florian.krupicka@googlemail.com> default * 3688:e24aa7996f9f 1.8-wsgi-fkrupicka/MoinMoin/ (userform/login.py userprefs/oid.py): Removed calls to request.getPathinfo
2008-06-19T18:57:31 <CIA-52> Florian Krupicka <florian.krupicka@googlemail.com> default * 3689:00a4837da41a 1.8-wsgi-fkrupicka/MoinMoin/web/request.py: Consolidate Request and Response into single object
2008-06-19T18:57:32 <CIA-52> Florian Krupicka <florian.krupicka@googlemail.com> default * 3690:8f3914a83410 1.8-wsgi-fkrupicka/MoinMoin/web/contexts.py: Further refinement to the Context-object model
2008-06-19T18:57:33 <CIA-52> Florian Krupicka <florian.krupicka@googlemail.com> default * 3691:eacb4c9e83e5 1.8-wsgi-fkrupicka/MoinMoin/wsgiapp.py: Reflect changes to Context-model and Request/Response in wsgiapp
2008-06-19T18:57:36 <CIA-52> Florian Krupicka <florian.krupicka@googlemail.com> default * 3692:ca0cf44dab89 1.8-wsgi-fkrupicka/MoinMoin/ (web/contexts.py wsgiapp.py): Moved request.clock into property
2008-06-19T19:01:36 <johill> I wish dennda would flood the channel like that ;)
2008-06-19T19:03:16 <xorAxAx> byeongweon: hi, can you please clean the fckeditor directory? there are orphaned files that are not necessary and werent added by your update. e.g. CVS
2008-06-19T19:03:50 <byeongweon> xorAxAx: I will check that.
2008-06-19T19:04:24 <zenhase> johill: well, not really :)
2008-06-19T19:04:45 <gizmach> dreimark: hi
2008-06-19T19:04:58 <zenhase> johill: i somehow skipped around a little bit in design the last 2 weeks, so i can experiment
2008-06-19T19:05:08 <zenhase> this kinda generates changes :)
2008-06-19T19:05:36 <zenhase> but not all of them were to stay in retrospective
2008-06-19T19:06:01 <johill> :)
2008-06-19T19:15:48 <dennda> johill: want me to commit every character seperately? :)
2008-06-19T19:16:45 <zenhase> :D
2008-06-19T19:19:09 <dreimark> hi gizmach
2008-06-19T19:19:10 <johill> heh
2008-06-19T19:19:43 <dreimark> and bbl
2008-06-19T19:20:05 * dreimark goes home and a little bit shopping
2008-06-19T19:29:34 <mmihaljevic> ok
2008-06-19T19:57:54 <CIA-52> Christopher Denter <moin GUESSWHAT the DASH space DASH station PERIOD com> default * 4035:de933cb64d4f 1.8-storage-cdenter/MoinMoin/storage/ (3 files in 3 dirs): storage: Item had a normal ._name-attribute. We discussed that a read-only .name-property would be better. Changing that.
2008-06-19T20:17:48 <ThomasWaldmann> re
2008-06-19T20:19:24 * ThomasWaldmann .o(changed to read-only because ....)
2008-06-19T20:21:33 <dreimark> re
2008-06-19T20:30:47 <dennda> johill: I cannot recall... Did you express any negative feelings wrt revision.revno? (I cannot find it in the logs, too)
2008-06-19T20:31:07 <johill> don't remember
2008-06-19T20:31:21 <johill> should be read-only I guess if present
2008-06-19T20:32:25 <dennda> ok
2008-06-19T21:19:13 <gizmach> bbl
2008-06-19T21:41:22 <dreimark> johill: I need later on a non internal call for _get_files of a page
2008-06-19T21:41:47 <johill> dreimark: no, you don't
2008-06-19T21:41:54 <johill> there will be no files of a page
2008-06-19T21:43:11 <dreimark> I know, but something similiar
2008-06-19T21:44:06 <dreimark> we don't want the same restrictions as wikipedia has, so the namespace of items (before attachments) are somehow realted to a page
2008-06-19T21:44:42 <dreimark> s/real/rela/
2008-06-19T21:50:14 <ThomasWaldmann> dreimark: you will have to search for subitems of the mimetype you want
2008-06-19T21:51:35 <dreimark> we should not run into this trouble that we are not able to use a name n-times for an item
2008-06-19T21:53:03 <dreimark> curently we can name an attachment 1.jpg on may pages
2008-06-19T21:53:43 <dreimark> many
2008-06-19T21:54:05 <ThomasWaldmann> that's no different from a subitem
2008-06-19T21:54:46 * dreimark is happy with that, so the method is somthing like all subitems and optional by mimetype
2008-06-19T21:55:33 <ThomasWaldmann> we'll just have a ItemList macro with some params
2008-06-19T21:57:41 <dreimark> yeah, because AttachFile will be killed I do need in 1.8+ a method like _get_files which is not internal defined
2008-06-19T21:59:26 <ThomasWaldmann> first we need to have a working backend, then we'll add stuff based on it
2008-06-19T21:59:47 <dreimark> ;) :)
2008-06-19T22:23:55 <CIA-52> Reimar Bauer <rb.proj AT googlemail DOT com> default * 85:d705644861dc 1.7-extensions/data/plugin/parser/text_x_arnica.py: text_x_arnica: removed html definition for mode2, renamed mode1 methods
2008-06-19T22:23:55 <CIA-52> Reimar Bauer <rb.proj AT googlemail DOT com> default * 86:88243aba10ce 1.7-extensions/data/plugin/parser/text_x_arnica.py: text_x_arnica: get_files by AttachFile to do the right encoding
2008-06-19T22:23:56 <CIA-52> Reimar Bauer <rb.proj AT googlemail DOT com> default * 87:d60f41c17f42 1.7-extensions/data/plugin/parser/text_x_arnica.py: text_x_arnica: renamed tools_html into html_tools
2008-06-19T22:23:57 <CIA-52> Reimar Bauer <rb.proj AT googlemail DOT com> default * 88:8b2450463344 1.7-extensions/data/plugin/CHANGES_arnica: updated CHANGES_arnica
2008-06-19T22:57:26 <dreimark> good night
2008-06-19T23:01:22 <ThomasWaldmann> gn dreimark
2008-06-19T23:02:20 * ThomasWaldmann compiles py2.6b1
2008-06-19T23:03:22 <CIA-52> Christopher Denter <moin GUESSWHAT the DASH space DASH station PERIOD com> default * 4036:ddc358588e67 1.8-storage-cdenter/MoinMoin/storage/ (__init__.py backends/memory.py):
2008-06-19T23:03:22 <CIA-52> storage (memorybackend): API detail change: If you create several revisions on
2008-06-19T23:03:22 <CIA-52> an Item without ever committing any of those, item.create_revision returns the
2008-06-19T23:03:22 <CIA-52> revision you created in the first place until you commit. Basic
2008-06-19T23:03:24 <CIA-52> commit-functionality on Items now works. I still need to handle clashes that may
2008-06-19T23:03:26 <CIA-52> occurr due to concurrent commits of the same revision.
2008-06-19T23:03:41 <dennda> johill: please please please review that change (not necessarily right now)
2008-06-19T23:03:57 * johill pulls
2008-06-19T23:07:06 <johill> dennda: "TODO: CLASH!"
2008-06-19T23:07:14 <johill> well, raise RevisionAlreadyExists?
2008-06-19T23:07:19 <dennda> hehe :)
2008-06-19T23:08:12 <johill> and I wouldn't use raise NoSuchRevisionError, "You are trying to commit...
2008-06-19T23:08:18 <dennda> given the time, let me think twice about that... nothing else?
2008-06-19T23:08:20 <johill> that's an API abuse error, not a real runtime error
2008-06-19T23:08:32 <dennda> ok
2008-06-19T23:08:35 <dennda> even better
2008-06-19T23:08:47 <johill> so imho it should just assert or raise no useful exception
2008-06-19T23:09:34 <johill> dennda: actually, it probably has to set item._uncommitted_revision to None?
2008-06-19T23:11:10 <dennda> if the revision already exists?
2008-06-19T23:11:44 <johill> yeah so you can merge and retry with the same item
2008-06-19T23:13:54 <dennda> merge?
2008-06-19T23:14:07 <dennda> doesn't that mean that you potentially lose your revision?
2008-06-19T23:14:20 <dennda> if you didn't bind it to any other name
2008-06-19T23:17:08 <johill> you have to find it to another name
2008-06-19T23:17:11 <johill> bind
2008-06-19T23:17:15 <johill> how else are you going to work with it?
2008-06-19T23:17:38 <dennda> item.create_revision(0).write_data(...).commit()
2008-06-19T23:17:44 <johill> eww
2008-06-19T23:17:50 <dennda> but I don't think write_data should return an item object
2008-06-19T23:19:02 <dennda> but what benefit is there if we set it to None wrt merging?
2008-06-19T23:34:18 <CIA-52> Johannes Berg <johannes AT sipsolutions DOT net> default * 3713:f42b05d07650 1.7/MoinMoin/auth/openidrp.py: bugfix: openid RP code had a bug when invalid usernames are entered
2008-06-19T23:36:02 <johill> dennda: the benefit is that you can detect the error
2008-06-19T23:36:14 <johill> and then load the revision you were trying to overwrite
2008-06-19T23:36:28 <johill> merge, and call create_revision again to save the merged data
2008-06-19T23:36:39 <johill> if you don't set _uncommitted_revision to None crate_revision would fail MoinMoin: MoinMoinChat/Logs/moin-dev/2008-06-19 (last edited 2008-06-18 22:15:02 by IrcLogImporter)
