[00:00] BlindWolf8: thanks [00:00] of course [00:00] wgz, then again it would be nice if Canonical gave me a VPS server for testing purposes ;-) ;-) [00:01] looks to be in... bzrlib\commands.pyo? [00:01] okay, one more bet for the filesystem watcher... [00:01] BlindWolf8: does using the bzr on the commandline also give him the same error? [00:02] or does it only happen when explorer is running? [00:02] he has never used the command line [00:04] would he just test his commit with -- bzr commit -m "test commit" -- ? [00:06] just `bzr add` should do [00:07] ok, looks like he solved it...he was getting the error when he was pulling updates [00:08] and his repo was in a Dropbox folder and his Dropbox client was on [00:08] okay, so two operations at once? [00:08] ah, right, dropbox and bzr don't play nicely together [00:09] any gotchas I should know about that kind of config besides...don't use it? ;-) [00:10] it's the same story as av software that grovels around keeping files open when bzr doesn't expect it [00:10] try and keep it out of .bzr folders [00:10] he has an impressive selection of other bugs in that log as well though [00:11] oh really? [00:11] lol [00:12] thanks for your help though [00:13] I see bug 820805 and and bug 901104 too [00:13] Launchpad bug 820805 in Bazaar "access denied on Pageant .pag file" [Undecided,Confirmed] https://launchpad.net/bugs/820805 [00:13] Launchpad bug 901104 in Bazaar Explorer "Permssion denied from file watcher when switching branches" [Medium,Confirmed] https://launchpad.net/bugs/901104 [00:13] ...and bug 557603 [00:13] Launchpad bug 557603 in QBzr "AttributeError on 'is_ignored' in treewidget filtering when adding in tree with conflicts" [Medium,In progress] https://launchpad.net/bugs/557603 [00:14] Yup, I posted about his issue in bug 820805 :-P [00:14] Launchpad bug 820805 in Bazaar "access denied on Pageant .pag file" [Undecided,Confirmed] https://launchpad.net/bugs/820805 [00:14] putty 0.62 fixes it [00:15] that's good, no one had actually confirmed that in the bug [00:16] it was odd since on his machine...0.61 never worked, but on MY machine and a clean VM 0.61 worked fine [00:16] so it must have been something on his machine besides putty [00:16] yeah, there are a few variables involved that made it tricky [00:17] anyway, please do keep complaining when things break :) [00:18] of course! :-) [00:18] you guys rock though [00:18] I remember when I was using Bazaar with a team in a game jam and we had issues [00:19] you guys were here :-) [00:20] I am gonna go. Thanks again! [01:14] commit, propose, and sleep time [01:21] as fun as arguing with python developers about whether nix or python is more at fault [01:22] can't we just agree that we all suck? [01:29] wgz: oh, the filesystem thing? [01:29] the bug is full of excitement :) [01:30] :) [01:35] okay, I'll be around a bit tomorrow but not doing normal hours [01:35] night all! [01:36] 'night wgz, don't dream in unicode! [01:37] ☁ [01:38] wgz: nevermind [01:38] * jelmer gets some sleep as well [02:13] Hello all. It seems my bzr repo got corrupted and I can't do anything. I always get this error message: bzr: ERROR: Config file file:///home/kroq-gar78/prog/python/primes/trunk/.bzr/branch/branch.conf is not UTF-8 encoded. Can anyone help please? [02:13] hi kroq-gar78 [02:13] i don't think it's corrupt, you just have something weird in that config file [02:13] open it in an editor and have a look [02:16] poolie: ok [02:16] put it in pastebin? [02:20] sure [02:20] is there anything obviously not ascii in there? [02:24] yup [02:25] http://paste.ubuntu.com/777015/ [02:31] *bump* sorry, being a little impatient [02:33] Just a little background, I'm not too sure what happened either, but the entire directory became binaries or something. Only about 3 of the files are still regular... [03:44] kroq-gar78, sorry was having lunch [03:44] that looks familiar [03:44] yay! [03:44] it is a windows executable [03:44] hope you weren't being sarcastic [03:44] no the mv\90\00 bit did [03:45] oh [03:45] :( [03:45] i have no idea what it is but it's not a bzr configuration file :) [03:45] maybe you copied it in there somehow? [03:45] that's what I thought [03:45] what i suggest is [03:45] 1- make a backup; 2- reboot and check the disk; 3- delete the bad config file; then you should be ok again [03:45] my whole directory got overridden by something, and some files even became directories :( [03:46] poolie: It was on a windows partition. How do I do that? [03:46] are you running linux or windows? [03:46] linux [03:46] ubuntu [03:46] i think you can run fsck on an ntfs partition [03:46] k I'll try it [03:47] making sure - it's "sudo fsck /dev/sd{whatever}" right? [03:47] unmount it first [03:47] yes [03:48] ah got it ty [03:48] fsck: fsck.ntfs-3g: not found [03:49] try sudo ntfsck DEV [03:50] Unsupported cases found. [03:50] That doesn't sound good... [03:50] if this is a dual boot machine perhaps you should boot into windows and check it there [03:50] ok [03:52] I really don't want to ;( I hate it. Is there a way where I can fix it on ubuntu? I'm just working on a copy that I pushed to Launchpad a little while back, and I probably didn't push a few commits. Can I the branch.config from there perhaps? [04:12] kroq-gar78, it's just configuration [04:12] you can probably just delete it [04:12] i'm just a bit concerned that if the filesystem is corrupt there might be other damage [04:12] so try just deleting that file [04:18] ok [04:21] bzr: ERROR: pack-names is not an index of type . [04:21] I think something seriously bad happened to that directory... [04:21] yeah i think so [04:22] sorry to hear it [04:22] meh [04:22] it's probably a lower level problem, not bzr [04:22] oh well [04:22] ok [04:22] good to know ;) blame windows! lol [04:22] jk [04:22] thanks anyway! [04:23] bye all! [05:58] poolie: ping [06:34] poolie: (nm, I'll try and catch you tomorrow) [06:56] fullermd_, hi [07:02] poolie: Was gonna see if you wanted to chat about checkout stuff. But I'm at the 23 hour mark and racing contra-conscious now. Tomorrow maybe, if you'll be around. [07:02] i will [07:02] i think you have a point there [07:03] Chilled legumes. I'll catch you after a solid 12 hours of sleep and 2 pots of coffee :> [08:09] 'hi all'.joyful() === nyuszika7h is now known as nyan-cat [09:01] Hi mgz wgz May I confirm, I got overlays working off my XP guest's vbox share. Was really easy (and documented indeed, I should have found it alone in here !! %ProgramFiles%/Bazaar/doc/tbzr/preferences.html) [09:02] So I just added "remote = True" to [queried_drives] section in tbzr.conf. Session restart seemed required (I guess I could have just restarted tortoise cache process) [09:04] fyi such shared drive appears in XP guest as remote drive, but with a "VBoxSharedFolderFS" filesystem. Maybe that would allow tortoise to auto-enable that [09:04] Anyway, thanks again for your help yesterday, I was "3 feets under" with so many other things, much appreciated ^^ [09:05] caravel: mgz was up really late last night, thanks for the feedback (I'll try to point him at the log later) and happy to see you're out of trouble ! [09:05] vila: :) I could have lived without that of course, it's just my way to contribute, too ^^ [09:05] s/really late last night/& and won't probably be there before some more hours ;)/ [09:05] good day all [09:06] caravel: feedback is a very valuable form of contribution [09:07] by the way... if I manipulate shared repos alternatively from fedora host and xp guest... and using two different versions of bzr, am I running into trouble ? [09:07] * caravel guesses answer is YES, of course [09:08] caravel: you should be safe, [09:09] vila: fantastic, thank you -- will take the risk to try, then :D [09:09] caravel: if you use the same working tree via mounts... you may run into weird issues though [09:09] but the branches and the repositories are fully compatible as long as they use the same format (which is probably '2a' in your case, 'bzr info' will tell you) [09:11] vila: yes, same format of course. But what do you mean by wierd issues ? As I explained, fedora hosts the files, these repos are located in a folder it manages, and that is mounted in XP guest as a vbox share [09:11] we;;, the working trees are compatible too, but the way the OSes present the file systems is... less than ideal for us [09:12] ha, in that case you *may* see executable bits spuriously changing [09:12] or locks failing [09:12] hmmm ^^ I'll be careful then! cheers [09:13] (systematical backups and diffs to start with) [09:13] well, 'commit' is the best backup there :) [09:14] yeah right.... to yet another repo ^^ [09:14] exactly [09:14] caravel: bound branches are perfect for that [09:14] makes sense [09:15] ok, leaving the space - thanks again === nyan-cat is now known as nyuszika7h === Odd_Blok1 is now known as Odd_Bloke [10:04] hi [10:05] 'bzr help builder' says about {debupstream} but how to get full version from debian/changelog? [10:05] I want to get 4.6.2-9ubuntu1 not just 4.6.2 [10:11] ok, found {debversion} [10:52] jelmer, I have formed the opinion that git-svn would work better if it was more like bzr-svn and stored metadata in SVN properties, instead of storing metdata in the commit logs (and thus by definition rewriting your local history every time you dcommit). Do you have an opinion? [10:59] hrw: yep [10:59] hrw: that might not work on launchpad yet though, it's a fairly recent addition, and launchpad is a bit behind on its bzr-builder [10:59] jelmer: would be nice to have those tags documented in 'bzr help builder' [10:59] launchpad is behind on many things [10:59] hrw: it is actually, are you on precise? [11:00] jelmer: precise [11:00] hrw: hmm, I guess the latest versio might not be packaged yet then [11:00] it's documented in trunk in "bzr help builder" [11:00] jelmer: http://pastebin.com/sP6bSHSp [11:01] indeed [11:01] hrw: it's in the bzr-builder package (not bzr itself) [11:01] btw - https://code.launchpad.net/~hrw/+recipe/gcc-4.6-armel-cross-daily is using branch which is at r51 but *** 0.7.2-0ubuntu1 0 [11:01] ops [11:01] *** 0.7.2-0ubuntu1 0 [11:01] this is installed one [11:06] awilkins: I'm not sure if I care about git-svn :) What's wrong with bzr-svn? [11:07] jelmer, It's not what's wrong with bzr-svn... I suspect it's "what's wrong with SVN that Git copes with better than Bazaar" [11:07] jelmer, I have different reasons I like them both ; bzr-svn is much easier to work with and has fewer annoyances and caveats [11:08] On the other hand, Git copes much better with things like, for example, people creating "branches" by branching the code, then deleting it all and replacing it with their patched copy [11:08] Which breaks the history in SVN and thus also in Bazaar, but Git just takes this in it's stride because a tree, is a tree [11:09] awilkins: I never used bzr-svn but used git-svn for years [11:10] Also it copes better with some of the quirks of SVN merges which don't always just patch the files in situ - if the merge is entirely from the remote side, it will just copy the file iNode from the remote branch, which results in a copy in SVN and also breaks the history in Bazaar which has no concept of this [11:11] So the first case is annoying and stems mostly from stupid SVN users not understanding how their own VCS works, but the latter case is entirely legitimate [11:12] yeah, I think we have a long open bug about copy tracking :( [11:13] awilkins: so I'm not entirely sure. I don't see a particular reason why it couldn't be done [11:14] jelmer, My contention is that the current way that git-svn stores metadata - by putting a git-svn ID in the commit log, which doesn't get pushed up to the SVN repository - is the reason that it can be a little inadequate in terms of 2-way interoperation with SVN via Git [11:15] And that it would do better by taking a leaf out of your book and storing metadata in the SVN repository as bzr-svn does [11:16] awilkins: how would pushing that metadata help though? [11:17] jelmer, You can pull multiple Bazaar branches from the same SVN branch and they all end up interoperable with very little effort [11:17] I don't think the same is true of git-svn or articles like this wouldn't occur : http://blog.tfnico.com/2011/03/dream-of-bi-directional-git-svn-mirror.html [11:19] I did have some problems with ghosts on other developers machines when merging feature branches into my SVN tracking trunk branch using Bazaar but I think they have been fixed [11:19] Whereas AFAICT the recommended stance with git-svn is to always rebase or cherry-pick your changes into your SVN tracking branch [11:20] awilkins: yeah, the ghost issues should all be resolved now [11:21] awilkins: you'll need ghost support in git, or push up all merged revisions into svn as well [11:24] CollabNet have just announced some kind of git / SVN bridge and hopefully we might get to see what that does in time [11:26] My employer uses their offering for hosting some projects, so it would be nice to be less ad-hoc about it [11:44] Yeah, it'd be interesting to see what CollabNet have done [11:46] vila: if you have a chance, a review of https://code.launchpad.net/~jelmer/bzr/merge-hooks/+merge/86395 would be great [11:46] (I'm working on some bzr-builddeb patches that use it) [11:47] ha crap, reviewed it in my bed but my brain isn't wired to lp [12:08] jelmer: reviewed, small tweaks [12:11] jelmer: by the way, about your CC reviews, I always get what is posted on lp, so your CC is always a dupe. If you still want to do that, please use vila+bzr instead vila in the email so at least the duplicates are filtered in the same mailbox ;) [12:11] they cause matrix glitches otherwise ;) [12:12] s/instead/instead of just/ [12:23] vila: ah, sorry [12:24] jelmer: no worries [12:26] jelmer: it's slightly annoying because I read one mailbox at a time and getting dupes in different places is... I prefer dupe reviews than no reviews, but no dupes is even better :-) [12:40] vila: the only argument in MergeHookParams that seems relevant for pre_merge / post_merge is _Merger [12:41] vila: the others are all specific to the individual file [12:41] yeah, I'm not sure it's worth adding a level of indirection around it... [12:42] the only risk I can think of is if we add an attribute that a hook introduces [12:42] I guess we could add a separate Params class for merge-wide hooks ? [12:43] that may seem a bit useless today but Merger is already so complicated :-/ [12:46] jelmer: forget about that part for now, we'll see how it comes out when a couple of such hooks have been written [12:47] jelmer: I don't think too many people will rush to write them so fixing them will still be an option if needed [12:49] hmm, on the other hand, actual file merge hooks handles the first call as a special case... perfect candidates for your new hook [12:49] which in turn raises a question though: what about ordering ? [12:50] po_merger for example will clearly benefits by establishing once and for all which '.pot' files exist [12:50] but if running your quilt hook modify the existing .pot files... boom [12:51] jelmer: just food for thought, out of scope for your proposal [12:54] * wgz bugs someone to review https://code.launchpad.net/~gz/bzr/fix_win32utils_deprecations/+merge/86213 [12:55] vila: ordering is a really hard problem, because we don't know what the other hooks are that are installed [12:56] vila: but it's an interesting point [12:56] wgz: I have to head into town, will have a look after I get back [12:56] if vila doesn't beat me to it :) [12:56] * vila lunch ;) [12:56] wgz: btw, what's the status on the post_connect hook branch? [12:56] wgz: you're back ? [12:57] oh ! [12:57] wgz: welcome back, the log said you had a busy night, you should read it though, caravel wanted to thank you ;) [12:59] I see, thanks! [12:59] wgz: approved, you could have landed it without review I'd say [12:59] I like rubber stamps :) [13:00] jelmer: status of post_commit is change the name, document that smart clients don't really behave the same way, and add some tests [13:01] I'm meant to be reading some books, but will try and do that before I leave today as well [13:03] wgz: thanks! [14:24] woot, my wireshark dissector for the bzr protocol just landed \o/ [14:28] jelmer, nice [14:33] wgz: books ? Come on, our proposals are not *that* long ;-p [14:33] jelmer: woot [14:33] jelmer: in other news, care to have a look at get_transport_from_url which is the main user of possible_transports and reconsider your belief that possible_transports is read-only ? [14:34] jelmer: I'm trying to reply to the relevant review but lp... is in limbo [14:35] vila: ah, you're right [14:36] jelmer: the whole idea behind possible_transports is to transparently collect all transport used making sure no duplicates are kept (handwave but see the assertionError above the .append) [14:36] vila: I guess the fact that we do sometimes manually add things to possible_transports was confusing me [14:36] yup, for seeding [14:36] vila: I'll fix it up, thanks [14:37] np, thanks for using it ;) === yofel_ is now known as yofel [15:24] jelmer: thanks for approving https://code.launchpad.net/~vila/bzr/907268-bazaar-DEFAULT/+merge/86536 , how about its pre-requisite ? :-D [15:24] https://code.launchpad.net/~vila/bzr/906897-quoting-stores/+merge/86526 [15:26] vila: that branch scares me a bit, but I'll have a look [15:26] vila: I just reviewed your memory-stack branch, fwiw [15:26] oh, cool [15:28] jelmer: nothing to be afraid of, everything is covered by tests :) And quite some were missing. You could try to read configobj.Config._quote but... the points I made in the proposal are not that obvious from reading the code [15:29] jelmer: and sorry about the apparent deletion of a bunch of tests, there was a massive duplication with the same classes duplicated [15:29] vila: ah, ok [15:31] vila: these complexities are one of the reasons why I think ini files aren't appropriate for use in format files [15:31] vila: for configuration files (where we want users to be able to edit them directly) I think they make a lot more sense [15:36] jelmer: ha, was just thinking about reviewing again to summarize, let's discuss here [15:37] what I care about is that we use a format that allow us to backport only once [15:37] and that we define a limited API on top of it for what we need in older bzr releases [15:38] from the standup, this means: is there at least a required feature, if yes, the object cannot be open [15:38] vila: I think the current format gives us that - we can add more optional lines in the future (followed by something different than the word "feature") later if we need to [15:38] any format will do as long as it can represent a required feature today [15:38] *but* [15:39] I tweaked the code a bit yesterday to actually allow ignoring *anything* after "optional ", not just optional features [15:39] we already have several available formats and I see no point in introducing a new one that has yet to demonstrate it can cope with semi-arbitrary additions [15:40] rio, bencode or the ini-like are all capable of that and I prefer to use them over a new one [15:40] vila: that just means layering this format on top of an existing one [15:40] the ini-like one is easier to read for debugging purposes or even for users [15:41] layering the features we need on top of an existing one you mean ? [15:41] gha [15:41] vila: it requires a complex parser though, and means extra overhead we open a branch/tree/repository/dir [15:41] the functionalities (features is ambiguous here) [15:42] lost in the noise and better than backporting [15:42] a handful of lines won't make a difference [15:42] whatever we use to parse them [15:43] we currently parse a whole config file each time we access an option and it never came up in profiles [15:44] vila: it's the overhead of the objects involved in the ini parser [15:44] vila: and generating / parsing ini files there are lots of quirks that are unnecessary, like the stuff you're hitting just now [15:45] irrelevant, the stuff I'm hitting is only when quoting is required [15:45] vila: I'm saying we're layering one format on another, because we don't use ini/rio/bencode as a format [15:45] vila: but we still have the overhead of considering whether we need to quote, etc [15:45] vila: we create *a lot* of formats in the testsuite for example [15:45] none of the options already migrated (except for the infamous stacked_on_location) needs quoting [15:45] vila: each make_branch_and_tree call reads 4 format files [15:46] vila: when we use bencode/rio/ini we just create another format that's layered on top of bencode/rio/ini [15:46] and all of them being empty are parsed instantly [15:46] vila: we're just reading from something that's richer than plain text [15:46] wait, [15:47] vila: and we have to make sure that only e.g. the 'features' section is used, that all entries in the features section have a valid necessity set, etc [15:47] hold on [15:47] the user will never edit that, he never edit it for now [15:48] vila: when we write that file we would write it through configobj, right? [15:48] we generate the content and our needs are pretty simple [15:48] yes [15:48] the point is that it's easy to add more stuff that will be ignored by previous bzr releases without having to backport [15:49] and separate the API (is_a_feature_required) from the format itself [15:50] vila: if we use configobj to write the files, then it will do things like arbitrarily quote [15:50] only if required [15:50] since I fail to see while you would want to use values that needs quoting, it's irrelevant [15:50] vila: but the overhead of all that stuff is still there [15:51] overhead << IO [15:51] vila: and we can end up accidentally quoting stuff that doesn't need quoting, or reading back quotes where they weren't there [15:51] only if quoting is required, that's why it took me so long to encounter the issue [15:51] vila: what's the advantage of that compared to the current format though? [15:51] vila: I'm sorry, I still don't see it. [15:51] single backport [15:51] vila: We have single backport now too. [15:52] only for the format you have already defined and tested [15:52] vila: and we will need to backport more in either case, when we add more required stuff in the future. [15:52] if you need more, you'll need to backport more [15:52] vila: the format I have defined allows arbitrary optional stuff. [15:52] vila: we need to backport more with an ini-based file format too [15:52] what do you mean by 'more required stuff' ? [15:53] no we won't need to backport anything if we decide that a feature can create its own section for its own needs for example [15:53] vila: if we want to add more data to the format file in the future (that is not features), but required [15:53] can you give an example ? [15:53] vila: features wouldn't be allowed to add sections in the format file, bzr would have to error out if there are unknown sections [15:54] why ? [15:54] vila: because we can't just ignore unknown stuff - it makes it impossible to extend the format file in the future [15:55] vila: and I don't see what sort of sections features would have to add [15:56] that was just an example of an alternative to allow features to add parameters [15:56] s/was/is/ [15:57] the point is that is_a_feature_required() can be implemented and still works if the underlying format receives additions [15:58] vila: but those additions can only be optional [15:58] did you turn the tables ? [15:58] :) [15:58] vila: and the current format allows for that as well - it just requires optional stuff that is added to be prefixed by "optional ", and leaves the possibility open to add mandatory stuff [15:58] not without backporting [15:59] vila: without backporting [15:59] then I return your previous objection: vila: because we can't just ignore unknown stuff - it makes it impossible to extend the format file in the future [16:00] vila: what about it? The current format still allows adding mandatory stuff [16:00] then where do you draw the line about what can be added ? [16:01] without requiring a backport [16:02] vila: mandatory stuff will always require a backport, that's inherit in the fact that it's mandatory [16:02] vila: *inherent [16:02] huh ? [16:03] I thought mandatory features will block opening the objects unless a plugin provides the feature [16:03] no backport involved here after the initial one [16:03] you don't intend to add nested tree support via backport right ? [16:03] vila: Ah, sorry, I think I was being quite vague [16:04] vila: To support features at all, we will only need a single backport in both cases [16:05] I fail to see how your parser will extract more stuff than what it currently supports [16:05] vila: what else does it need to support features? [16:05] vila: in the future, I mean [16:05] vila: and how would an ini format be better? [16:06] I don't know what else it needs, but I know that the ini format provides a bunch of ways to add stuff while still being able to extract what the old bzr releases will care about: is at least one feature required [16:07] that's the point, [16:07] vila: in what way does the current format *not* support that? [16:07] additional parameters as you mention ? [16:08] something we haven't think about yet because we haven't implemented features ? [16:08] vila: if there are additional paramters they will still recognize there is a mnadatory feature they don't support [16:08] but would it be able to provide the additional stuff to the features ? [16:09] vila: no, but neither would the ini format [16:10] vila: we need a change to the feature API to allow that sort of thing, and that's fine [16:10] come on, of course the ini format can, it just has to pass the underlying configobj [16:10] vila: exposing the internals as part of the API?? [16:11] that's private to the feature, who cares [16:11] or rather, what's the problem ? [16:12] vila: each plugin would have to know about the internals of the branch-format file [16:13] vila: it makes e.g. an Repository.update_features({"foo": "required"}) API impossible [16:13] impossible ? That seems a bit strong no ? [16:14] vila: no - the only API we could provide is direct access to the configobj, if we want the kind of extensibility you suggest [16:15] and how does your format address that without backport ? [16:15] hmm [16:15] it seems we're not making progress here and we still don't know what this format should support and provide [16:16] vila: I don't really care about plugins being able to register features with new fancy stuff in older bzr versions [16:16] vila: I mostly care about making it possible for older bzr versions to ignore optional stuff [16:16] so far, the only thing that seem to be required is a (possibly empty) list of optional features and a (possibly empty) list of required features [16:17] anything else can be added by the plugins *outside* the format file no ? [16:17] vila: right - and even the list of names allows for some flexibility (like versioning) [16:18] yup, we said the version shouldn't be part of that (or tricked with names) [16:18] vila: the settings thing is something I wondered about, but e.g. mercurial seems to have gotten away with a plain list of features without settings (see .hg/requires) [16:18] I saw [16:19] I 100% agree about older bzr ignoring optional features [16:19] I don't really want us to paint ourselves into a corner by making it impossible to add new stuff to the format file, but I also don't think we'll be doing more of it soon. [16:19] I very hesitant about required features, but since that won't happen today, I won't block on detecting them either [16:19] right, [16:20] so how about we clearly document that we just won't add new stuff for '2a' ? [16:20] vila: I think it's more likely we'll extend the set of necessities in the future [16:20] what's a necessity ? [16:20] vila: how necessary it is to have a feature present [16:20] vila: "required" and "optional" are the current possible values [16:21] what else do you have in mind ? [16:21] vila: the spec talks about another necessity "read-optional" [16:21] vila: IOW, you can read this repository but if you want to write to it you have to have the plugin present [16:21] justasec [16:21] ha [16:21] example ? [16:21] vila: that's very useful for stuff like bzr-git, which wants to make sure that a cache is up to date - and not spend 20 seconds each time it accesses a repository verifying that every bzr revision is in the bzr-git cache [16:22] ha, excellent [16:22] right, make that 3 lists then [16:22] write-only sounds a bit silly and probably impossible ;) [16:23] vila: there are probably more necessity values - like e.g. only being necessary for the direct writer of a repository, not a client that writes to it over HPSS [16:23] vila: optional and required are the extremes, the other necessities are somewhere in between them [16:24] but unkown... [16:24] vila: right - so we fall back to "required" if we find a necessity we don't know about [16:25] one sec [16:26] right, [16:27] nobody said features can't be provided by bzr-core and in this case, it doesn't matter if it's required as upgrading bzr itself is enough [16:27] so, falling back to required sounds good [16:28] optional, read-optional, required seems well defined enough and only require a name, additional stuff is plugin business [16:28] overhead now [16:29] your implementation already requires at least a set() and a dict() which will contains the strings, so if the parser throws away the parsed lines, the format overhead is peanuts [16:30] if we stick to three lines of python identifiers separated by commas, the parser is also trivial and as such, robust [16:31] the set is global, the dict is the only thing that is created for each format [16:31] (lines can start with optional, required, read-optional for debug, I won't mind ;) [16:32] ha, same set for all formats ? [16:32] vila: actually, that's a good point [16:32] why ? [16:32]