| Peng_ | The progress bars showing bandwidth usage is very cool, but why did it take 2.2 MB to download half a dozen revisions? :( | 00:00 |
|---|---|---|
| Peng_ | ...OK, a dozen revisions. | 00:00 |
| lifeless | Peng_: from a 1.9 format repo? if not, its because the index layer in < 1.9 is quite inefficient (which is why it was replace) | 00:00 |
| lifeless | alf: is bzr not doing something you want it to? | 00:02 |
| alf | lifeless: I would just expect bzr diff to inform me that the tree is not in sync with the branch tip (as bzr status does) | 00:05 |
| Peng_ | lifeless: Ah, right. (It was bzr.dev.) | 00:06 |
| lifeless | alf: ah! So the reason bzr diff doesn't do that is that its not really relevant to diff - diff is about textual changes, not overall status | 00:06 |
| lifeless | alf: diff also doesn't show pending merges for instance | 00:06 |
| alf | lifeless: I have (finally) understood what is going on and its necessity, I must however admit it is a bit unintuitive because of the difference in behaviour between local/remote push | 00:23 |
| RaceCondition | is it possible to use the bzr command inside a virtualenv that has been activated? | 00:24 |
| RaceCondition | right now it seems to me that no, but maybe there are workarounds | 00:24 |
| lifeless | whats a virtualenv? | 00:30 |
| RaceCondition | hmm, it works on the root level of a virtualenv, but not in a subdirectory that is a python module... | 00:30 |
| RaceCondition | lifeless: it's a Python tool for creating virtual environments for Python installations/apps | 00:31 |
| davidstrauss | What happens if you branch from a loomified branch? | 00:31 |
| lifeless | davidstrauss: you get a loom | 00:31 |
| lifeless | davidstrauss: with the state of the last record of the loom | 00:31 |
| lifeless | RaceCondition: bzr should just work regardless, unless you're only copying in some of the bzr modules | 00:33 |
| lifeless | RaceCondition: what error do you get? | 00:34 |
| RaceCondition | lifeless: that bzr cannot find bzrlib | 00:34 |
| RaceCondition | the cause of this issue is pythonpath actually | 00:34 |
| RaceCondition | http://dpaste.com/113360/ | 00:34 |
| lifeless | RaceCondition: 'python -c "import bzrlib"' | 00:34 |
| RaceCondition | it's different depending on which folder Python is run | 00:34 |
| RaceCondition | I guess it's a Python matter/queston, not a bzr one | 00:35 |
| lifeless | seems likely to me | 00:35 |
| RaceCondition | mercurial is having the same issue | 00:36 |
| lifeless | both hg and bzr use lazy imports | 00:36 |
| lifeless | how does virtualenv decide what to copy in ? | 00:37 |
| RaceCondition | lifeless: I dunno | 00:38 |
| RaceCondition | I'm neither a Python nor a virtualenv expert | 00:38 |
| lifeless | my guess is the lazy import nature | 00:39 |
| alf | lifeless: Thank you for the explanation, it has been very helpful | 00:41 |
| lifeless | alf: my pleasure | 00:41 |
| RaceCondition | lifeless: nope, it's because sys.path actually does not contain what needs to be there | 00:44 |
| jfroy|work | jelmer: ah, svn-upgrade is what I need if I want to move to bzr-svn 0.5 while keeping existing branches around, correct? My situation is a "trunk" branch in Subversion, a local trunk mirror Bazaar branch and a set of local and remote Bazaar branches created from that local trunk branch. | 01:08 |
| jelmer | jfroy|work: Only for your local branches that are not in svn | 01:11 |
| jfroy|work | none of them are besides trunk | 01:20 |
| jfroy|work | jelmer: and what is the correct procedure? upgrade bzr-svn, wipe the cache, nuke my local trunk, re-checkout from svn, then svn-upgrade all the local trunk branches? | 01:21 |
| ronny | *sigh* | 01:40 |
| ronny | jelmer: i hit a whole new kind of hell now that i dont only want to have a view on stuff like branches but also getting them from remotes in the various possible flavours | 01:42 |
| jelmer | ronny, hi | 01:42 |
| jelmer | jfroy|work, no need to wipe the cache (unless you've used experimental versions of bzr-svn 0.5) | 01:43 |
| jelmer | jfroy|work, no need to re-checkout from trunk | 01:43 |
| jelmer | jfroy|work, I wouldn't use svn-upgrade atm, pending LarstiQ's bug | 01:43 |
| jfroy|work | OK | 01:44 |
| ronny | jelmer: i cant find any reasonable model that fits all ways of bzr to get a repo/branch/workdir | 01:44 |
| jfroy|work | jelmer: so I can just update bzr-svn and move along? | 01:44 |
| jelmer | ronny, is your current interface definition up somewhere? | 01:44 |
| ronny | jelmer: no | 01:44 |
| jelmer | s/definition/design/ | 01:44 |
| ronny | jelmer: the whole checkout vs branch vs dir branch in repo is kina nasty cause bzr is the only one that is that "complex" there | 01:45 |
| jelmer | ronny, I don't think it's complex | 01:46 |
| jelmer | ronny, you basically have branches and trees, either of which can be present | 01:47 |
| jelmer | working trees always have a pointer to some branch | 01:47 |
| jelmer | that's it basically | 01:47 |
| ronny | jelmer: still, hg, git, darcs do all of that more simple | 01:48 |
| jelmer | ronny, more simple in what regard? | 01:48 |
| lifeless | gits index is approximately our tree | 01:48 |
| ronny | 1 repo, 1 workdir, 1 way to get it | 01:48 |
| jelmer | ronny: Bazaar is the same, 1 branch, 1 work directory - there's also only one way to get it if you ignore checkouts | 01:49 |
| jelmer | (which I think make sense if you do abstraction like that) | 01:49 |
| lifeless | git can do naked repos and trees without repos too | 01:50 |
| lifeless | you have to set environment variables though :) | 01:50 |
| ronny | jelmer: it gets nasty as soon as i want to track multiple remote branches in a single repo | 01:51 |
| jelmer | hi nevans | 01:51 |
| jelmer | ronny, How would you do that in darcs? | 01:51 |
| lifeless | ronny: I'd just ignore the repo, its not meant to be semantic; its all about branches | 01:51 |
| lifeless | s/its/they are/ | 01:51 |
| ronny | repos are kinda important, at least for monotone, git and hg | 01:53 |
| ronny | but those dont have brnaches as subdirs within repos, but as semantic entities | 01:53 |
| lifeless | ronny: all quite different though | 01:53 |
| lifeless | git branchs are refs in a repo; hg branches are unmerged revs in a single repo, and monotone branches are non-signed revs | 01:54 |
| lifeless | bzr branches are revision ids | 01:54 |
| ronny | lifeless: but they exist as actual entities in the fs | 01:55 |
| lifeless | ronny: yes, thats a key design point | 01:55 |
| lifeless | ronny: it gives them unique URL's | 01:55 |
| ronny | lifeless: but adds massive amounts of complexity to deal with for me | 01:56 |
| lifeless | ronny: in what way | 01:56 |
| ronny | and i think its important enough to deal with | 01:56 |
| lifeless | if its adding complexity for our users, we may need to change this, so I really would like to understand | 01:57 |
| ronny | lifeless: it makes getting a repo + branches really different from the others | 01:57 |
| lifeless | why worry about the repo | 01:58 |
| lifeless | why not 'get branches'? | 01:58 |
| jelmer | perhaps some background is required here | 01:58 |
| ronny | im intrested in sets of branches | 01:58 |
| ronny | not just one | 01:58 |
| jelmer | ronny, this is for your work on a vcs abstraction library, right? | 01:58 |
| ronny | jelmer: yeah | 01:58 |
| jelmer | lifeless, ^ | 01:58 |
| lifeless | I'd ffigured that much :P | 02:00 |
| ronny | and bzr always manages to look the most complex from *my* point of view | 02:00 |
| ronny | at things where the others have one oblivious way i see 3 different ways that are all valid | 02:00 |
| lifeless | its true that there are many combinations bzr supports; I think you'll find that git and hg both support the same things bzr does, but not as clearly in the UI | 02:01 |
| ronny | and the whole standalone branch vs dir branch in repo vs checkout is my most nasty thing i see | 02:01 |
| lifeless | which suggests to me that what jelmer said is very applicable - there is no need to represent everything in your library | 02:02 |
| lifeless | ronny: how is it nasty for you? | 02:02 |
| lifeless | (I'm not an ELIZA bot honest) | 02:03 |
| ronny | lifeless: it seems very complex | 02:03 |
| ronny | i learned dvcs with monotone | 02:03 |
| lifeless | ronny: tree.branch.repository | 02:03 |
| lifeless | ronny: three objects, left->right dependency so if you have tree, you always have branch and repo | 02:03 |
| ronny | so git/hg feel rather natural, but bzr is kinda alienating | 02:03 |
| ronny | this is mostly related to having n ways instead of just one | 02:04 |
| lifeless | ronny: but git has more than one way! and so does hg | 02:05 |
| lifeless | ronny: so I *fail* to understand that commend | 02:05 |
| ronny | lifeless: git/hg have only clone there | 02:05 |
| ronny | i fail to see how that can be more than one way | 02:06 |
| lifeless | ronny: uhm, sounds like there are wires crossed. | 02:06 |
| lifeless | ronny: are you talking about how to get a branch, or about the way things can be laid out on disk ? | 02:06 |
| ronny | lifeless: how to get a branch | 02:07 |
| ronny | or better a set of them | 02:07 |
| lifeless | 'bzr branch' is the only command in bzr to get a branch | 02:07 |
| lifeless | and we don't have a UI for getting a set of branches at the moment, not in the core | 02:07 |
| ronny | a clone in git/hg (or sync in monotone) always gets me the stuff thats currently up - including tracked branches | 02:08 |
| ronny | bascially i get my set of branches, then work on them like i need to | 02:09 |
| lifeless | well, hg doesn't do branches in a way thats friendly to that, but sure, git does | 02:10 |
| ronny | for me it makes no sense to limit dealing with them to exactly one at a time | 02:10 |
| lifeless | I'd use loom or jelmers colocated plugin to do that in bzr, if I felt the urge | 02:10 |
| ronny | colocated? | 02:11 |
| lifeless | jelmer wrote a plugin that gives something approximating git branch management | 02:12 |
| lifeless | I didn't think darcs did sets of branches either | 02:13 |
| lifeless | codeville either | 02:13 |
| jelmer | lifeless: Speaking of which, I'm still interested in feedback on the spec for that :-) | 02:13 |
| lifeless | svn doesn't | 02:13 |
| ronny | lifeless: darcs is kinda different | 02:13 |
| lifeless | jelmer: on my todo | 02:13 |
| jelmer | lifeless, cool, thanks! | 02:13 |
| ronny | and svn is just a workdir, the branches are always remote | 02:13 |
| lifeless | ronny: but remote branches are one per url, and a 'repo' may have thousands of unrelated things in it | 02:14 |
| lifeless | ronny: svn's branch management is actually quite similar to bzr IMO | 02:14 |
| lifeless | except in bzr they are typed rather than free-form (which is fugly) | 02:14 |
| ronny | lifeless: local+remote vs only remote | 02:15 |
| lifeless | ronny: URL based, which is all I'm talking about | 02:15 |
| lifeless | 'bzr branches' -> list of branches | 02:15 |
| lifeless | etc | 02:15 |
| ronny | lifeless: i dont actually care about url's, all i need is a name | 02:16 |
| lifeless | ronny: branch.get_nick() I think is the API, that will give you the name | 02:17 |
| tro | lifeless: is that plugin called loom? | 02:18 |
| lifeless | tro: which plugin? | 02:18 |
| ronny | lifeless: thats not my issue here, its the n ways to get the thing set up as well as the different fs layout | 02:18 |
| tro | the one that jelmer wrote to approximate git branch management | 02:18 |
| lifeless | ronny: you say there are n ways, but I only know of one way to get a branch to work on. | 02:18 |
| lifeless | ronny: which is 'bzr branch' | 02:18 |
| jelmer | tro, it's bzr-local-branches | 02:19 |
| lifeless | tro: no loom is for patch management; ^ is jelmers | 02:19 |
| tro | ah, ok | 02:19 |
| jelmer | tro, it mainly does multiple branches in one dir though, no tracking of remotes like git | 02:19 |
| ronny | hmm, so its just as powerfull as hg bookmarks | 02:20 |
| tro | that would work for me, i think. my use case is that i've got a large project that takes like 30 mins to setup in my IDE. it's not fun to branch around into separate directories because of that | 02:20 |
| ronny | hmm | 02:20 |
| lifeless | tro: you do know about 'bzr switch' yes ? | 02:20 |
| tro | lifeless: yes, it's what i use, but then i have to think about where to put the repository. then when i wanna switch i have to remember what the branches are called | 02:21 |
| tro | maybe all i need is a plugin with a "switch history" | 02:22 |
| ronny | reminds me, i'll have to implement "switch" support too | 02:22 |
| * igc lunch | 02:22 | |
| lifeless | tro: I see. What I generally do is just have the repo at ~/src/project, then branches under that are cheap | 02:22 |
| tro | so i could do "bzr switch -1" to go back to the previous see branch | 02:22 |
| tro | seen* | 02:22 |
| lifeless | tro: for C projects I just checkout --lightweight one branch to 'working' and then swtich from there | 02:23 |
| lifeless | tro: thats a nice idea | 02:23 |
| tro | i'll see if i can do something about it :) | 02:23 |
| lifeless | tro: perhaps the bookmarks plugin could grow that, writing something to the tree | 02:23 |
| tro | i'll take a look at the bookmarks plugin, thanks | 02:24 |
| ronny | hmm | 02:25 |
| ronny | i'll ignore checkouts and figure a good way to deal with repos + branch dirs | 02:26 |
| thumper | where has bzr shelve put the shelf now? | 02:36 |
| tro | thumper: i think it's inside .bzr/checkout/shelf , if it's a checkout, anyway | 02:37 |
| thumper | can I just move that to another checkout? | 02:38 |
| lifeless | probably | 02:40 |
| thumper | yep, it works | 02:42 |
| lifeless | statik: ping | 02:45 |
| statik | lifeless: hi | 02:59 |
| lifeless | abentley: replied to our thread; hoping we can get consensus before you crash | 03:04 |
| lifeless | statik: mailed you about ack ;) | 03:04 |
| statik | lifeless: yeah, just saw it. i'll have to try bzr-search out again, but this week might be pretty tough. i'm on the wrong side of a deadline, and flying to london on saturday | 03:05 |
| * statik pulls the latest trunk of bzr search | 03:07 | |
| abentley | lifeless: Quite a while 'till we crash, but I doubt we'll get consensus. | 03:16 |
| lifeless | abentley: ah. Well I want to make sure I don't cause problems for lp or bb. As long as I know what those constraints are I'll be happy | 03:17 |
| abentley | lifeless: Well, the nub of it is that I don't believe there are sane default paths for plugins. | 03:18 |
| abentley | lifeless: There are sane paths for given clients, but they'll vary based on circumstance. | 03:19 |
| lifeless | abentley: I believe the default should be what bzr does, because that is least confusing for users of bzrlib. | 03:23 |
| abentley | lifeless: I believe the default should be to do nothing, because that has the least potential to explode when the user's system bzr is upgraded. | 03:25 |
| abentley | I think that bzrlib.plugins is, itself, confusing. Because it doesn't behave the way other packages do. | 03:26 |
| lifeless | abentley: how does it behave differently? | 03:26 |
| spiv | I'm a little bit uncomfortable about bzrlib doing that, it feels a bit too much like assuming bzr is the only client. I don't feel strongly about it, it just makes me slightly nervous. | 03:26 |
| lifeless | spiv: qualify 'that' please. | 03:26 |
| abentley | lifeless: Importing from bzrlib.plugins imports things from directories other bzrlib/plugins | 03:27 |
| lifeless | abentley: thats standard python functionality | 03:27 |
| lifeless | abentley: the __path__ in the module controls the search | 03:27 |
| lifeless | we used to have some really complex stuff, but I unified it with default python logic some time ago | 03:27 |
| abentley | lifeless: I know how it works. It's still unlike every other package I've encountered. | 03:28 |
| lifeless | ok | 03:28 |
| spiv | lifeless: doing things at import time, basically. I think this case is likely to be just fine, it's just the sort of thing worries me slightly :) | 03:28 |
| abentley | It is magic. | 03:28 |
| lifeless | it was fine for years. I think a totally different change borked things | 03:30 |
| spiv | Whatever we do, we should clearly document both how to get a typical bzr plugin path, and how to do something different that will make e.g. launchpad feel safe. | 03:30 |
| abentley | lifeless: To me, that totally different change brought the problems with default paths to the fore. | 03:31 |
| abentley | lifeless: That's why I submitted a patch to stop loading default paths, instead of reverting the other change. | 03:31 |
| spiv | I am a little curious about the use case for "import bzrlib.plugins.FOO" without first telling bzrlib to configure the plugins path. Just interactive convenience? | 03:31 |
| lifeless | spiv: sane default, interactive convenience | 03:32 |
| lifeless | I'd say load all plugins by default too but that makes me twitch too. (Not to mention that there is a bootstrap issue trying to do --no-plugins if we did that). | 03:33 |
| spiv | Right, loading all plugins by default conflicts with being able to write other than bzr on bzrlib. (And even conflicts with bzr itself, as you say.) | 03:35 |
| spiv | Whereas this proposal just sets some configuration a certain way by default... It's still a bit weird that "import bzrlib.plugins.FOO" won't work, but "import bzrlib.plugin; import bzrlib.plugins.FOO" will. | 03:36 |
| spiv | Or is bzrlib.plugin always imported by bzrlib? I guess it is. | 03:37 |
| lifeless | spiv: loading bzrlib.plugin doesn't set a path either | 03:46 |
| lifeless | spiv: importing bzrlib.plugins sets a path of ['.'] basically, because thats what python does | 03:46 |
| jamesh | it might be useful to have an API like "load this one particular plugin using the same logic to find it as load_plugins() does" | 04:07 |
| jamesh | given that "import bzrlib.plugins.FOO" won't find everything | 04:08 |
| lifeless | jamesh: there is such an api - 'import bzrlib.plugins.PLUGIN' | 04:08 |
| lifeless | jamesh: what won't it find? | 04:08 |
| jamesh | lifeless: I've had problems using that to find plugins in ~/.bazaar/plugins. Has that been fixed since then? | 04:08 |
| lifeless | jamesh: did you file a bug? They are asserted to be the same | 04:09 |
| jamesh | lifeless: if they are under bzrlib/plugins, things work as you describe | 04:09 |
| jamesh | lifeless: I didn't know that it was a bug. | 04:09 |
| lifeless | jamesh: were you acting as a bzrlib client? | 04:09 |
| jamesh | lifeless: yes. | 04:09 |
| jamesh | if by that you mean a Python program that imports bzrlib | 04:10 |
| lifeless | jamesh: then this is likely exactly the bug I'm talking about | 04:10 |
| lifeless | jamesh: starting in (I think) 1.11, you have to manually set the plugins path. Which is what I want to back out. | 04:10 |
| jamesh | lifeless: hmm. I've got bzr-1.10 here | 04:11 |
| lifeless | jamesh: does bzrlib/__init__ contain a call to set_plugins_path()? | 04:11 |
| jamesh | lifeless: no | 04:12 |
| lifeless | ok, then it was 1.10 that this got changed in | 04:12 |
| lifeless | diff __init__.py with 1.9 :) | 04:12 |
| asabil | what would be the best way to iterate over the revisions of a branch starting from revision 1 and preserving the merging history ? | 04:31 |
| asabil | seems like branch.get_history () only returns the mainline rev-ids | 04:31 |
| asabil | s/get_/revision_/ | 04:31 |
| lifeless | you'll need a topological sort | 04:53 |
| lifeless | and you have to rewrite most of the merged nodes too because they may refer to nodes you are rewriting | 04:53 |
| lifeless | anyhow,the tsort module is your friend | 05:02 |
| nDuff | ooh | 05:08 |
| * nDuff wonders if bzrlib.tsort.TopoSort is faster than the topological sort in the NX graph library he's using elsewhere. | 05:08 | |
| lifeless | nDuff: worth giving it a spin | 05:10 |
| lifeless | abentley: /win 51 | 05:26 |
| lifeless | bah | 05:26 |
| lifeless | abentley: I'd really like to get something that won't break lp/hitchhiker/bundlebuggy etc. I *will* be putting up a patch though, so please help me to put one up that doesn't break those other tools. | 05:26 |
| === mneptok_ is now known as mneptok | ||
| lifeless | also, freenode fail. yay | 05:27 |
| === thumper_laptop is now known as thumper | ||
| rockstar | abentley, you're not around are you? | 06:32 |
| vila | hi all | 07:01 |
| sohail | bzr version 1.11, bzr update => *** Bazaar has encountered an internal error. | 07:12 |
| sohail | _unpack_entry() got an unexpected keyword argument 'entry_cache' | 07:12 |
| sohail | any ideas? | 07:12 |
| spiv | sohail: pastebin a full traceback? | 07:18 |
| spiv | sohail: also, maybe try --no-plugins. | 07:18 |
| sohail | spiv, will do | 07:19 |
| sohail | spiv, can you access https://bugs.launchpad.net/bzr/+bug/321765 | 07:20 |
| ubottu | Ubuntu bug 321765 in bzr "When executing bzr update, get error: _unpack_entry() got an unexpected keyword argument 'entry_cache'" [Undecided,New] | 07:20 |
| spiv | sohail: looks like a bug! | 07:23 |
| spiv | congrats ;) | 07:23 |
| sohail | spiv, groan... | 07:24 |
| sohail | workaround possible? | 07:24 |
| sohail | hmm | 07:24 |
| * sohail notices no bzr stash | 07:24 | |
| sohail | ah bzr shelve | 07:25 |
| spiv | sohail: looking... | 07:26 |
| spiv | sohail: that's a strange one. I can't see the cause by reading the code, but I'd expect to be able to. | 07:28 |
| sohail | spiv, yep | 07:30 |
| sohail | I was looking at the code too | 07:30 |
| sohail | no idea | 07:30 |
| igc | hi vila | 07:30 |
| vila | hi Ian ! | 07:30 |
| spiv | sohail: can you print the type of self in that failing _unpack_inventory method? | 07:31 |
| sohail | spiv, ok | 07:31 |
| sohail | spiv, so you mean print type(self) yeah? | 07:31 |
| spiv | Right. | 07:31 |
| spiv | igc, vila: good evening | 07:32 |
| sohail | <class 'bzrlib.xml5.Serializer_v5'> | 07:32 |
| sohail | that doesn't help! | 07:32 |
| spiv | Heh, no. | 07:32 |
| spiv | I guess I was forgetting that you were using --no-plugins, so it was hardly going to be otherwise. | 07:33 |
| sohail | spiv, I think I may have got it? | 07:34 |
| sohail | it should be inheriting from v7 not v6 | 07:34 |
| spiv | No, I don't think so. | 07:35 |
| spiv | Besides, Serializer_v7 defines _unpack_entry with the same signature. | 07:35 |
| sohail | no, v6 does not have the cache parameter | 07:35 |
| sohail | b/c v6 inherits from v8 | 07:36 |
| spiv | You must be looking at a different 1.11 than me... | 07:36 |
| sohail | I must be... | 07:36 |
| sohail | hm.. wtf | 07:36 |
| spiv | Because in mine, v6 inherits from v8 (as you say), and v8 defines _unpack_entry with the same signature as v7. | 07:37 |
| sohail | wt | 07:37 |
| sohail | f | 07:37 |
| sohail | I'm using bzr from ppa or something | 07:37 |
| sohail | I wonder if it didn't uninstall properly | 07:38 |
| sohail | doh that must have been it | 07:38 |
| sohail | spiv, I think that's it! | 07:40 |
| sohail | gigantic PEBKAC | 07:40 |
| spiv | sohail: phew :) | 07:40 |
| sohail | wait... still checking | 07:40 |
| sohail | yep, all good | 07:41 |
| sohail | geez | 07:41 |
| sohail | thanks spiv | 07:41 |
| spiv | sohail: maybe file a bug about the packaging? :( | 07:41 |
| spiv | Oh, d'oh, you already closed your bug just before I did :) | 07:42 |
| sohail | spiv, no what happened was that I had the ubuntu version of it | 07:42 |
| sohail | switched to ppa before uninstalling | 07:42 |
| sohail | and presumably THEN removed it (or something) | 07:42 |
| sohail | but still... it shouldn't have royally screwed up like that | 07:43 |
| * sohail shrugs | 07:43 | |
| spiv | Yeah, neither the ubuntu or the ppa versions should do that. | 07:43 |
| * sohail unshelves and continues | 07:43 | |
| spiv | First time I've heard of it happening! | 07:43 |
| sohail | I'm pretty sure I did something wrong | 07:43 |
| sohail | so unless it happens again, I'm happy | 07:44 |
| spiv | Ok :) | 07:44 |
| sohail | bzr shelve is quite cool | 07:44 |
| hno | bzrtools needs to be updated in launchpad ppa. | 08:49 |
| Lo-lan-do | Can the rebase plugin help move revisions between "unrelated" branches? | 09:27 |
| Lo-lan-do | Use case: after the GForge→FusionForge fork^Wrenaming, we're considering starting with a mirror of the previous SVN repository. | 09:28 |
| Lo-lan-do | Same contents, same history, but different repo UUIDs and therefore different bzr revision ids. | 09:29 |
| Lo-lan-do | But I'd like to graft the previous branches onto the trunk based on the new SVN repo. | 09:31 |
| Lo-lan-do | I suppose rebase could help, but I fear it would complain about unrelated branches. And the doc doesn't help me much. | 09:31 |
| * Lo-lan-do tries with --onto | 09:32 | |
| Lo-lan-do | Doesn't seem to work :-/ | 09:37 |
| === asac_ is now known as asac | ||
| asabil | Lo-lan-do: try to run bzr replay | 10:44 |
| Lo-lan-do | Aha! | 10:44 |
| asabil | it is a hidden command from bzr-rebase | 10:45 |
| * Lo-lan-do tries that | 10:45 | |
| Lo-lan-do | Not working either. I get conflicts :-( | 10:47 |
| === Guest44711 is now known as jelmer | ||
| jelmer | asabil, Lo-lan-do: replay and rebase are in essence the same thing, just different UIs | 11:14 |
| CaMason | Is it possible to utilise 'external' branches within a project, similar to svn:externals ? | 11:18 |
| Odd_Bloke | I just updated to bzr HEAD and am impressed with the new pull output. So kudos to whoever did that. :) | 11:33 |
| === sabdfl1 is now known as sabdfl | ||
| Odd_Bloke | jelmer: Do you have your subvertpy packages available anywhere? | 11:50 |
| jelmer | Odd_Bloke, yes, http://people.samba.org/bzr/jelmer/bzr-svn/debian | 12:02 |
| jelmer | ehum | 12:02 |
| jelmer | Odd_Bloke, yes, http://people.samba.org/bzr/jelmer/subvertpy/debian :-) | 12:02 |
| jelmer | Odd_Bloke, there's also packages uploaded to the subverpty PPA and NEW | 12:03 |
| jelmer | CaMason, that's nested branches, which have been stalled for a while | 12:03 |
| Odd_Bloke | jelmer: Yeah, I saw them in NEW. But I don't want to have to wait. :p | 12:03 |
| asabil_ | how can I create a commit with 2 parents using bzrlib ? | 12:05 |
| jelmer | Lo-lan-do, the problem is that the file ids are still different even if the revision ids are not | 12:06 |
| jelmer | Lo-lan-do, bug 231674 | 12:07 |
| ubottu | Launchpad bug 231674 in bzr-rebase "can't replay, need maptree support in rebase" [Wishlist,Triaged] https://launchpad.net/bugs/231674 | 12:07 |
| jelmer | asabil: You can specify the parent ids to the commit function | 12:07 |
| Odd_Bloke | jelmer: Thanks. :) | 12:07 |
| jelmer | asabil_: You can specify the parent ids to the commit function | 12:07 |
| jelmer | Odd_Bloke, just "bzr builddeb http://people.samba.org/bzr/jelmer/subvertpy/debian" should build you a package | 12:07 |
| asabil_ | ok thanks jelmer | 12:07 |
| === asabil_ is now known as asabil | ||
| === poolie2 is now known as poolie | ||
| hsn_ | !pastebin | 12:23 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 12:23 |
| asabil | can someone help me with this code: http://pastebin.com/m315e7782 | 12:23 |
| asabil | after a while I get the following error: | 12:24 |
| asabil | bzr: ERROR: Working tree is out of date, please run 'bzr update'. | 12:24 |
| hsn_ | http://paste.ubuntu.com/110254/ - i can not get bzr shelve work in 1.10 or 1.11, it reports same error | 12:25 |
| asabil | hsn_: run bzr break-lock | 12:26 |
| Lo-lan-do | jelmer: That makes sense. I guess I'll go the old way then, and apply diffs by hand. | 12:27 |
| hsn_ | asabil: it doesnt help, after breaking lock i will get could not obtain lock error again | 12:27 |
| vila | jelmer: did you see my comment on bug #256612 | 12:28 |
| ubottu | Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [High,In progress] https://launchpad.net/bugs/256612 | 12:28 |
| jelmer | vila, could we do password prompting for 401 responses? | 12:29 |
| vila | err, we already do password prompting for 401, are you asking for *user* prompting instead ? | 12:30 |
| vila | jelmer: anyway, that would be a different problem, 256512 is about getting the credentials from svn when we connect to a svn server | 12:32 |
| jelmer | vila: ah, I wasn't aware we did password prompting already | 12:32 |
| jelmer | I'll have a look at the svn side of things | 12:32 |
| vila | I'm pretty sure we fail right now because we have no *user* to provide which a svn credential store plugged into authentication.conf *can* provide | 12:33 |
| vila | from there bzr can prompt for password, fail its probe, fall back to bzr-svn probe, which finally can succeed | 12:34 |
| vila | That's the scenario you and I identified months ago for which there was no good solution. Remember that ? | 12:35 |
| hsn_ | my error is same as this: https://bugs.launchpad.net/bzr/+bug/305006 - so its currently fix commited to devel bazaar version? | 12:36 |
| ubottu | Ubuntu bug 305006 in bzr "shelve fails with "Could not acquire lock"" [Undecided,Fix committed] | 12:36 |
| asabil | jelmer: any idea about my code ? | 12:39 |
| jelmer | vila, yeah | 12:39 |
| jelmer | asabil, which code? | 12:40 |
| asabil | http://pastebin.com/m315e7782 | 12:40 |
| asabil | I am trying to rebuild a branch from another branch | 12:40 |
| asabil | in the same way that bzr-rebase does | 12:40 |
| asabil | and it fails when it encounters a merge | 12:41 |
| jelmer | any reason for not just using rebase? | 12:41 |
| jelmer | asabil, How does it fail? | 12:42 |
| asabil | jelmer: I am trying to write bzr filter-branch | 12:43 |
| jelmer | asabil, ah, cool | 12:43 |
| asabil | it fails asking for update to be ran | 12:43 |
| asabil | when I add tree_to.update () before the commit | 12:43 |
| asabil | it fails with conflicts | 12:43 |
| jelmer | asabil, why whould you be calling update() ? | 12:48 |
| asabil | jelmer: its asks for it | 12:49 |
| james_w | I don't think you actually need to *do* a merge do you? | 12:51 |
| asabil | james_w: I just copied what bzr-rebase does | 12:51 |
| james_w | do you not know what the tree of the revisions is supposed to look like at each point? | 12:51 |
| asabil | I do know | 12:51 |
| james_w | you can just put the tree in that state and use "tree.set_parent_ids()" and then commit in that case | 12:53 |
| asabil | james_w: and how can I put it in that state ? | 12:54 |
| asabil | sorry I am not yet familiar with theses apis | 12:55 |
| james_w | well, that depends on where you get the information from | 12:55 |
| james_w | presumably you check out the old revisions tree | 12:55 |
| james_w | apply the filter-branch transform on it | 12:55 |
| james_w | and then commit the result | 12:56 |
| asabil | I just need the no-transform case for now | 12:56 |
| asabil | I will find my way later | 12:56 |
| james_w | for a merge it will be the same thing, but you set an extra parent or three on the working tree before committing | 12:56 |
| james_w | ok, just checking it out and committing | 12:56 |
| james_w | though I see your point now, I'm not sure what the API is for checking out the old revision tree in to the new working tree | 12:57 |
| james_w | vila: is RedirectRequested something new? | 12:58 |
| asabil | that's what I am looking for | 12:58 |
| vila | james_w: no | 12:59 |
| vila | james_w: I think it's even pre-1.0... | 12:59 |
| james_w | vila: hmm, my transport.do_catching_redirections code appears to have just broken | 12:59 |
| james_w | e.get_target_url() | 13:00 |
| james_w | AttributeError: 'RedirectRequested' object has no attribute 'get_target_url' | 13:00 |
| vila | wow, where are you using such code ? | 13:00 |
| LarstiQ | vila: is ~/.netrc supposed to work for regular sftp:// and bzr+ssh:// usage yet? | 13:00 |
| james_w | vila: in a plugin(ish) | 13:00 |
| vila | james_w: ouch, I may have broken backward compatibility then, but on the other hand there was several bugs there | 13:01 |
| james_w | I need to follow some launchpad redirects to get the librarian url for some files I need | 13:01 |
| james_w | vila: no problem, this code is only running in one place, so it's not difficult to fix | 13:02 |
| james_w | vila: do you know off-hand what the new way of doing that would be? | 13:02 |
| vila | james_w: give me a minute to page-in the code | 13:02 |
| * vila 's memory acess times is in the minute range... what a shame | 13:02 | |
| james_w | vila: thanks. I can search if you are busy with something else | 13:02 |
| jelmer | vila, what sort of settings should I expect in the credentials dictionary ? | 13:04 |
| vila | james_w: bzr diff -c3903 in trunk should be the most helpful for you | 13:04 |
| === lamont` is now known as lamont | ||
| vila | jelmer: you mean when credential_store.decode_password is called ? | 13:05 |
| jelmer | vila, yeah | 13:05 |
| james_w | vila: perfect, thanks | 13:06 |
| vila | you should have host, user, password, the later can be None, | 13:07 |
| vila | optionally path can be present and scheme could be there too | 13:08 |
| jelmer | vila, what about realm? | 13:09 |
| vila | jelmer: you get the section defined in the authentication.conf file, if the user put a realm, you get it | 13:09 |
| jelmer | vila, yeah, but the HTTP implementation will be prompting my credentials provider | 13:10 |
| jelmer | vila, ideally without a section in authentication.conf | 13:10 |
| vila | jelmer: I don't parse that | 13:11 |
| jelmer | vila, So when a user connects to a svn http server, the http server will send back a 401 | 13:11 |
| jelmer | that will prompt bzr to look for credentials | 13:12 |
| vila | the http client will then query authentication.conf | 13:12 |
| jelmer | and will ask all the credentials providers for credentials for that server | 13:12 |
| vila | that's not how it works | 13:12 |
| jelmer | ok, in that case I misunderstood | 13:13 |
| vila | The user decides where he wants to put his credentials, he declares that through authentication.conf | 13:13 |
| vila | There is no way to say: spread my credentials here and there | 13:13 |
| jelmer | so the user can't use more than one credentials tore? | 13:13 |
| vila | He can, but only one by section in authentication.conf | 13:13 |
| vila | Actually that's wrong: "There is no way to say: spread my credentials here and there" | 13:14 |
| vila | That's even the purpose of authentication.conf, I should have say: we don't query credential stores blindly, the user tell us how | 13:15 |
| jelmer | that just means the user has to edit authentication.conf for every svn repository they connect to | 13:15 |
| jelmer | even if they already have credentials for that repository in ~/.subversion/ | 13:15 |
| vila | Well, authentication.conf uses a 'first match wins' rule, so you can define a fallback section with svn as the credential store | 13:16 |
| jelmer | yes, but in that case you can't really use netrc as well | 13:17 |
| vila | ...except you'll need the actual url in that case (or usr/host/realm/path already splitted) | 13:17 |
| jelmer | vila, I would expect the netrc credentials provider to do the splitting in that case | 13:19 |
| vila | jelmer: meh, the nertc provider is onvoked only if people mentioned it in authentication.conf | 13:20 |
| jelmer | vila, Yeah, but I think that's wrong too | 13:20 |
| jelmer | one of the nice things about netrc is seamless integration, and being able to use your existing stored credentials | 13:21 |
| jelmer | having to set things up in authentication.conf per host just defeats that | 13:21 |
| vila | you can set things up by scheme, host, host+port, many combinations exists | 13:22 |
| vila | you can set things up by scheme, host, host+port, many combinations exist | 13:23 |
| LarstiQ | aha | 13:23 |
| vila | That's the whole point of authentication.conf, it can even be used for smtp | 13:23 |
| LarstiQ | I have to mention netrc in authentication.conf? | 13:23 |
| * LarstiQ tries that | 13:23 | |
| jelmer | yes, but the point is that you have to set up something in authentication.conf, most likely for each host | 13:23 |
| LarstiQ | jelmer: I use [DEFAULT] | 13:23 |
| vila | scratch that 'most likely' :-) | 13:24 |
| vila | There is more than one way to use it :) | 13:24 |
| jelmer | vila, I don't think it's that easy to scratch | 13:24 |
| vila | You can even set by domain | 13:24 |
| LarstiQ | vila, jelmer: so if I understand it correctly, it would be nice to try the svn credential store for svn, even if not explicitly mentioned in authentication.conf, but that is not currently possible? | 13:24 |
| jelmer | I have different usernames on different hosts, and even some hosts with and without Subversion | 13:25 |
| jelmer | LarstiQ, yes | 13:25 |
| jelmer | LarstiQ: and for the netrc store | 13:25 |
| LarstiQ | vila: scheme won't work for bzr-svn because you can't distinguish http bzr and http svn? | 13:25 |
| jelmer | LarstiQ, yes | 13:25 |
| vila | LarstiQ: yes | 13:25 |
| vila | jelmer: you can even set by user/host | 13:25 |
| jelmer | vila, yes, but that requires configuration in authentication.conf | 13:25 |
| jelmer | which is unnecessary imho | 13:26 |
| LarstiQ | vila: it is not clear to me from http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html how to tell authentication.conf to use .netrc | 13:27 |
| vila | jelmer: explicit is better than implicit for credentials, especially since we are not trying to address storing crentials securely, delegating that to extrenal credentials stores | 13:27 |
| LarstiQ | brb, will check the code after that | 13:28 |
| vila | and since that will be externalized, user must have control over it | 13:28 |
| LarstiQ | vila: yes but, for svn, isn't it rather obvious to try the svn credential store always? | 13:28 |
| vila | LarstiQ: So because svn is a special case we should change the general case ? Or should we provide some hook for svn purposes instead ? | 13:29 |
| vila | jelmer: the whole purpose of authentication.conf is to give user control over which credentials to use when, if you don't need that, fine, don't use it, but leave the user the option to use it | 13:32 |
| LarstiQ | vila: I don't think svn is a special case actually. For ssh/sftp, I'd also expect to try ~/.ssh/config | 13:32 |
| jelmer | vila: it means users will *still* be confused when they try to use https:// | 13:32 |
| vila | LarstiQ: ssh is out of scope as said in the spec :) | 13:32 |
| jelmer | vila, also because it doesn't prompt for a username | 13:33 |
| vila | jelmer: prompting for user is a different problem, it can be wprked around so far by specifying the user in the url, so we can neglect it in this discussion | 13:33 |
| LarstiQ | vila: ah hmm, does that explain why my [DEFAULT] authentication.conf setting is not helping me with sftp:// ? | 13:33 |
| vila | LarstiQ: did you try -Dauth ? | 13:34 |
| LarstiQ | (it does actually work for bzr-svn) | 13:34 |
| LarstiQ | vila: no, good point | 13:34 |
| * LarstiQ goes off and tries | 13:34 | |
| jelmer | vila, that's more specifically where this bug is about imho | 13:34 |
| jelmer | vila, if you specify a username atm you'll just be prompted a couple of times | 13:34 |
| LarstiQ | vila: 0.592 Using authentication section: 'DEFAULT' | 13:35 |
| LarstiQ | 0.720 ssh implementation is OpenSSH | 13:35 |
| jelmer | no 401 error | 13:35 |
| LarstiQ | vila: not really helpful | 13:35 |
| jelmer | hi poolie | 13:35 |
| vila | LarstiQ: if you try to use auth.conf for passwords you should get a warning, using for users should work | 13:36 |
| LarstiQ | vila: I get no warning. | 13:37 |
| * LarstiQ is on bzr.dev r3958 | 13:37 | |
| vila | LarstiQ: Strange, I'm a bit lost here, I *think* either the ssh client thinks it can authenticate without password or should query auth.conf and issue a warning | 13:38 |
| LarstiQ | vila: I'll try to debug it further | 13:39 |
| * LarstiQ afk for a bit | 13:39 | |
| vila | jelmer: regarding "if you specify a username atm you'll just be prompted a couple of times", that's the precise point I want to address, the yse should be queried at most once | 13:39 |
| vila | once the http connection is set, we should be able to share it without having to prompt again | 13:39 |
| LarstiQ | right | 13:40 |
| LarstiQ | vila: but, I'd like to be prompted again if I mistype my password. Though not infinitely. | 13:40 |
| jelmer | vila: That's not what this bug report about though, it's about users getting "Unable to handle 401" when they are trying to contact a authenticated http server and are not specifying a password. | 13:40 |
| vila | Whether that can be achieved in a single bzr command may be a bit ambitious right now, but at least issuing an svn command should populate some credetial store that can then be resued y bzr | 13:40 |
| jelmer | vila: bzr-svn will already use authentication.conf | 13:40 |
| vila | jelmer: the point is to have a svn-specific credential store that can *provides* the credentials that svn knows about | 13:41 |
| vila | that's where netrc is an *example* on how to implement one for svn | 13:42 |
| jelmer | vila: the point of this bug report? in that case the bug report would be "bzr asks for a password more than once" | 13:42 |
| vila | ghaa, let's start again | 13:42 |
| jelmer | vila: There's no point in having a svn-specific credentials store with the current API; the use in having that would be seamless integration, but that's pointless if there's additional configuration required. | 13:43 |
| vila | jelmer: I agree we disagree: I think there is value in having the ability to say "I want to use svn credentials for these sections, not for these" if only as a way to get rid of cruft | 13:44 |
| jelmer | vila: I see *some* use in that, I don't think that's what this High-importance bug is about | 13:45 |
| vila | jelmer: I'm not *against* allowing bzr-svn to be a fallback for authentication.conf if you want seamless integration | 13:45 |
| vila | That's two different use cases | 13:45 |
| jelmer | ok | 13:46 |
| vila | jelmer: When we diagnosed the root cause together, the consensus (as I remembered it) the bug was that bzr was stopping to query other formats because it couldn't authenticate | 13:49 |
| jelmer | I think we can agree about that, actually - I still don't think this is the "unknown 401 response" bug | 13:49 |
| vila | that is the cause I try to address here, not querying for user is another bug in my mind | 13:50 |
| vila | and it appears my mind is wrong | 13:50 |
| vila | since bug 216614 is a duplicate, I thought it was still stnding on its own | 13:50 |
| ubottu | Launchpad bug 216614 in bzr "should not immediately abort of .bzr/format can't be opened (dup-of: 256612)" [Undecided,Incomplete] https://launchpad.net/bugs/216614 | 13:50 |
| ubottu | Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [High,In progress] https://launchpad.net/bugs/256612 | 13:51 |
| jelmer | ah, ok | 13:51 |
| jelmer | I'll open a separate wishlist bug about allowing to query other stores without additional configuration | 13:52 |
| jelmer | does that sound reasonable? | 13:52 |
| vila | so if we can't share these credentials, the user is prompted, the result thrown away before svn provides the right ones automatically and we still get bug reports :) | 13:52 |
| vila | jelmer: sounds reasonable *too* | 13:53 |
| vila | At least we could discuss it separately | 13:53 |
| jelmer | vila: Yeah, I think that would be a good idea | 13:54 |
| vila | jelmer: pfew :) | 13:55 |
| jelmer | vila: Ok, I've got the credentials store implemented | 14:04 |
| vila | jelmer: So, to clarify, my initial question regarding my comment... lol | 14:04 |
| vila | exactly, thanks, | 14:04 |
| jelmer | vila: I'm not seeing any of the other keys from my section in authentication.conf | 14:05 |
| vila | where ? | 14:05 |
| jelmer | vila, it would be nice to get the realm the http server sends available somehow | 14:05 |
| vila | right, I may have been wrong in my previous comments, that can be considered a bug in the actual implementation | 14:05 |
| vila | it should provide more context | 14:05 |
| vila | i.e. the actual url (and realm for http) for which the query is done | 14:06 |
| jelmer | yeah, that would be nice - Subversion uses the realm as key, so I need that to do the querying | 14:07 |
| jelmer | should I file a bug about that? | 14:10 |
| vila | right, just checked it, the actual implementation provides only user and section name (that can be used to get the whole section if needed) but it should also provides the actual context | 14:11 |
| vila | jelmer: yes, do so, I'll fix asap | 14:11 |
| vila | in fact I think it's buggy for netrc too, the tests are probably too restrictive | 14:12 |
| vila | jelmer: apart from the realm what is used for the key ? | 14:13 |
| jelmer | vila: realm and optionally username | 14:13 |
| vila | no host ? no path ? | 14:13 |
| vila | no port ? | 14:14 |
| vila | no scheme ? :-) | 14:14 |
| jelmer | vila: sorry, host/port as well | 14:14 |
| jelmer | they're included in the realm in a specific format | 14:15 |
| vila | ok, host/port/realm and no path then ? | 14:15 |
| jelmer | e.g. "<http://svn.collab.net:80> Subversion Committers" | 14:15 |
| jelmer | yeah, no path | 14:15 |
| vila | ok, good | 14:16 |
| vila | So that you can use different user by using different realms and you don' care about path | 14:16 |
| jelmer | vila: I also think the keyring support in GNOME would be another good candidate for Bazaar querying all credentials stores | 14:19 |
| jelmer | vila: Since that will require you to confirm (using a GUI thingy) when you're using one of its credentials | 14:19 |
| vila | jelmer: I'm going step by step here because I've yet to define how we want to *save* credentials from bzr | 14:21 |
| vila | If you can imagine querying them all to *find* credentials, you don't want to do that to save them | 14:21 |
| jelmer | yeah, that makes sense | 14:21 |
| vila | And if you want to be explicit about where to save them, not doing it to find them will lead to surprising behaviors | 14:22 |
| jelmer | well, it would depend on the ordering you use I guess | 14:22 |
| jelmer | Subversion would be a candidate for fallback credentials - you should never have to store new credentials there | 14:23 |
| vila | I try to take the most paranoiac users into account there, that means being explicit | 14:23 |
| jelmer | and it would only have to be queried if all else has failed | 14:23 |
| vila | jelmer: agreed for svn being a fallback | 14:23 |
| jelmer | vila: For gnome-keyring I would personally want to use that as an alternative to authentication.conf, so not using authentication.conf at all | 14:23 |
| vila | jelmer: once we figure a way to handle the explicit cases, finding ways to make them implicit should be easy | 14:24 |
| vila | but, yes, back in the early days of auth.conf, I looked into gnome-keyring and OSX keychain as credential stores and I realized they have different APIs so I tried to provide a single point where any user will have a minimal setup to do in auth.conf. making the minimum == 0 is the holy graal :) | 14:27 |
| vila | For example, I can imagine people going from svn to bzr on the same host yet wanting to use different users for their svn repo and their bzr repo | 14:28 |
| vila | I can also imagine they want to *keep* the same user though | 14:29 |
| jelmer | vila: They should be able to differentiate by including the username in the URL | 14:30 |
| vila | jelmer: yes, but we want to get away from embedding user in urls so that people can share urls | 14:31 |
| vila | :) | 14:31 |
| jelmer | vila: ah, hmm | 14:31 |
| jelmer | ok, my SubversionCredentialsStore works if I hardcode scheme, port, host and realm \o/ | 14:31 |
| vila | jelmer: sorry, I should have told you that :-/ | 14:32 |
| vila | errr, no, I think I don't understand *why* that succeeds in fact :) | 14:32 |
| jelmer | (this is with configuration in ~/.bazaar/subversion.conf) | 14:33 |
| jelmer | argh | 14:33 |
| jelmer | (this is with configuration in ~/.bazaar/authentication.conf) | 14:33 |
| jelmer | I've hardcoded those variables in config.py, not in the configuration file | 14:34 |
| vila | ha, good :) | 14:34 |
| vila | So that means you know how to *query* svn credentials ! Great, that's the part I missed ! | 14:35 |
| phinze | so how do you #bzr people maintain your local file structure | 14:38 |
| phinze | specifically, how do you organize mirror and task branches | 14:38 |
| jelmer | I have one repository per project | 14:39 |
| jelmer | and then various branches in there, mixing mirror and task branches (usually I name the mirror branches after the people they're from) | 14:39 |
| phinze | so all your branches just sit in the root of the local repo then? you don't mirror the directory structure of any shared repo | 14:40 |
| jelmer | phinze, no | 14:41 |
| jelmer | phinze, I mean yes to your first question, no to the second | 14:41 |
| phinze | jelmer: yeah sorry making it difficult for you :) | 14:41 |
| phinze | okay, so are your mirrors branches or checkouts | 14:41 |
| jelmer | vila: Yeah, I did the work for that already a bit earlier. | 14:42 |
| jelmer | phinze, branches | 14:42 |
| phinze | sounds good, thanks for giving me a use case :) | 14:42 |
| vila | jelmer: where can I have at look at that ? 0.4 ? 0.5 ? | 14:43 |
| jelmer | vila: 0.5, auth.py | 14:43 |
| vila | jelmer: thanks | 14:44 |
| jelmer | vila, if you need a good test repository: http://chaina.tigris.org/svn/chiana/trunk | 14:45 |
| jelmer | (user: guest, password: guest) | 14:45 |
| vila | jelmer: great, copying that in due place | 14:47 |
| === rizitis is now known as rizitis_away | ||
| tro | why is it that branching is so much faster in git than in bzr? is it because git doesn't do any copying? | 15:11 |
| Jc2k | tro: you need to give more context than that | 15:12 |
| tro | Jc2k: just a simple branching op. git is almost instant. bzr takes a while. does git not make any copies of WT files? | 15:13 |
| Jc2k | if you dont use a shared repository branching is like git clones with --local --no-hardlinks | 15:13 |
| Jc2k | and if you dont use a shared lightweight copy then it copies the WT files | 15:13 |
| Jc2k | so its a double hit | 15:13 |
| tro | oh i see. what's a shared lightweight copy? a lightweight checkout from a shared repo? | 15:15 |
| Jc2k | yes | 15:15 |
| tro | my use case is windows with a large tree (i think around 10k files). so no hardlinks :( | 15:16 |
| Jc2k | make sure your share repo has --no-trees, or you'll still get duplicated WT's and it will be slow | 15:16 |
| Jc2k | *shared | 15:16 |
| tro | right. that's what i've got. | 15:17 |
| Jc2k | then it should be quick | 15:17 |
| tro | so a lightweight checkout/switch would be faster, right? my shared repo is local. | 15:17 |
| Jc2k | yes | 15:17 |
| tro | thx | 15:17 |
| Jc2k | theres a plugin somewhere to help you with this layout.. let me find you the link.. | 15:18 |
| Jc2k | tro: https://lists.ubuntu.com/archives/bazaar/2009q1/051801.html | 15:24 |
| Jc2k | tro: that plugins gives you a 'start' command which is like branch and switch in one swoop | 15:25 |
| tro | oh cool. thanks. | 15:25 |
| Jc2k | tro: also http://theironlion.net/blog/2009/01/23/more-advanced-bazaar-concepts/ | 15:25 |
| Jc2k | (tho that post is a little different to what you want, you can adjust it easily enough) | 15:26 |
| poolie | jam, if you're around, re debug flags | 15:43 |
| jam | morning poolie | 15:43 |
| poolie | did you mean you wanted me to add a new test, or just that i might have broken an existing one? | 15:43 |
| jam | poolie: sorry, I thought you might have broken an existing one | 16:05 |
| poolie | i might | 16:07 |
| poolie | i ran the obvious tests, doc, help etc | 16:07 |
| luke-jr | jelmer: 0.5 rc 2 anytime soon? :/ | 16:07 |
| jelmer | luke-jr, 3 more bugs to fix | 16:08 |
| luke-jr | :/ | 16:08 |
| jelmer | luke-jr: Nothing should be blocking you from using the 0.5 branch though.. | 16:08 |
| luke-jr | it's not packaged | 16:08 |
| jelmer | luke-jr, Not packaged for what? | 16:09 |
| luke-jr | Gentoo | 16:09 |
| luke-jr | crap, none of those 3 look easy enough for me ☹ | 16:10 |
| luke-jr | actually, I was assuming the Triaged | 16:11 |
| jam | poolie: "test_osutils.py" around line 1504 | 16:12 |
| jam | poolie: TestResourceLoading.test_resource_string | 16:13 |
| jam | also, poolie, what do you think about the "remove whitespace bandaid" patch. Should we land it now or wait for a release? | 16:13 |
| poolie | i think now | 16:13 |
| poolie | ah you're right | 16:16 |
| fullermd | Hm. Progress bar seems to have some interactions with commands that print out stuff while they're running through the bars. | 16:17 |
| fullermd | e.g. running info on the main bzr.dev branch. | 16:17 |
| ollie | ahh i am going around in circles with bzr mv bzr: ERROR: Could not move awards_entry_form.php => awards_entry_stage1.php: system/application/views/forms/awards_entry_stage1.php is already versioned. | 16:18 |
| fullermd | repository branch: http://bazaar-vcs.org/bzr/bzr.dev/ | 16:18 |
| fullermd | \ 1kB @ 0kB/s | 16:18 |
| fullermd | Related branches: | 16:18 |
| fullermd | ollie: Well, if the new location is already a versioned file, you can't move an old file to the same place. | 16:18 |
| fullermd | What are you wanting to accomplish? | 16:18 |
| ollie | bzr rm --keep awards_entry_stage1.php: system/application/views/forms/awards_entry_stage1.php | 16:18 |
| luke-jr | jelmer: any ETA on those 3 bugs? | 16:19 |
| ollie | bzr mv --after system/application/views/awards_entry_form.php system/application/views/forms/awards_entry_stage1.php | 16:19 |
| ollie | bzr: ERROR: Could not move awards_entry_form.php => awards_entry_stage1.php: system/application/views/forms is not versioned. | 16:19 |
| ollie | don; | 16:19 |
| jelmer | luke-jr, about a week probably | 16:19 |
| ollie | don't get it firstly it tells me it is already versioned so i guess it needs to be unversion | 16:19 |
| ollie | so i unversion it and it tells me it is not versioned! | 16:19 |
| luke-jr | :/ | 16:20 |
| * fullermd frowns. | 16:20 | |
| luke-jr | jelmer: happen to recall the rev that fixed the bug I need? | 16:20 |
| jelmer | luke-jr, I'm not sure which bug that was, sorry | 16:20 |
| jelmer | luke-jr, you should be able to just checkout bzr-svn in your ~/.bazaar/plugins | 16:20 |
| luke-jr | jelmer: somethign about it not liking tags | 16:20 |
| ollie | fullermd: i have renamed a file so i want to tell bzr the file has moved so i keep its history | 16:20 |
| luke-jr | jelmer: cd ~/.bazaar/plugins && bzr co lp:bzr-svn ? | 16:21 |
| jelmer | luke-jr: Yeah | 16:21 |
| fullermd | Note that it's talking about the dir the second time, not the file. | 16:21 |
| fullermd | Doesn't seem to make sense... | 16:21 |
| ollie | but i can't version a dir without adding its contents.. | 16:21 |
| fullermd | Well, of course you can. You just can't version its contents without versioning it. | 16:22 |
| fullermd | So if _entry_stage1.php were versioned, forms/ would have to be. But you only unversioned the .php (unless you're skipping steps in the explanation), so forms/ should still be. | 16:22 |
| luke-jr | jelmer: after renaming it to 'svn', 'bzr branch' errors out immediately | 16:23 |
| ollie | cracked it :) | 16:23 |
| ollie | so i have to unversion each file manually | 16:24 |
| ollie | but keep the dir versioned | 16:24 |
| luke-jr | http://pastebin.com/m7f856376 | 16:25 |
| fullermd | Right. Can't move into a dir that isn't versioned. | 16:25 |
| luke-jr | jelmer: curiously, I don't see the warning on line 79 anywhere | 16:26 |
| jelmer | luke-jr, I've pushed a fix | 16:27 |
| jelmer | luke-jr, http://people.samba.org/bzr/jelmer/bzr-svn/0.5 | 16:28 |
| luke-jr | bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.5/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 16:29 |
| jelmer | luke-jr, you'll need to use "bzr branch" rather than "bzr co" | 16:29 |
| jelmer | (I thought that bug was fixed?) | 16:29 |
| luke-jr | :/ | 16:30 |
| luke-jr | oh, maybe 'bzr pull' doesn't work in a 'bzr co' | 16:30 |
| luke-jr | which makes sens | 16:30 |
| fullermd | Well, I'm pretty sure it _works_... | 16:32 |
| jelmer | ah, in that case it makes sense | 16:32 |
| fullermd | Just doesn't do what you're trying to do in this case :p | 16:32 |
| jelmer | if you run "bzr pull" it will try to update the master branch as well | 16:32 |
| jelmer | and you don't have write access to the master branch | 16:33 |
| luke-jr | ☺ | 16:33 |
| luke-jr | ugh, bzr branch is so slow | 16:33 |
| Lo-lan-do | Use git then. Oh wait, you can't, git people don't care about interoperability. | 16:34 |
| luke-jr | File "/home/luke-jr/.bazaar/plugins/svn/__init__.py", line 100, in <module> | 16:34 |
| luke-jr | from bzrlib.plugins.svn import format, revspec | 16:34 |
| luke-jr | ImportError: cannot import name format | 16:34 |
| jam | poolie: care to chat a bit about the code.python.org email? | 16:34 |
| jelmer | luke-jr, Please have a look ~/.bzr.log | 16:36 |
| luke-jr | jelmer: curiously, the ~/.bazaar one seems to break the main install too | 16:36 |
| luke-jr | jelmer: it says the same thing | 16:38 |
| luke-jr | should I remove the system bzr-svn? | 16:39 |
| jelmer | luke-jr, pushed another fix | 16:39 |
| jelmer | luke-jr, any chance you can try with that (pushed to the samba.org location) | 16:39 |
| luke-jr | curiously, I couldn't even 'bzr info/pull' without moving it out of the plguins dir | 16:43 |
| === bac is now known as bac_lunch | ||
| luke-jr | jelmer: ok, now I get bzr-svn: at least subvertpy 0.5.0 is required | 16:47 |
| luke-jr | jelmer: subvertpy is part of bzr-svn tho ;) | 16:47 |
| jelmer | luke-jr, no, it's a separate package these days | 16:47 |
| luke-jr | it was in rc1 :/ | 16:49 |
| jelmer | luke-jr, Yes, but no longer | 16:49 |
| luke-jr | lp:subvertpy ? | 16:50 |
| jelmer | luke-jr, yep, or one of the tarballs | 16:50 |
| luke-jr | ugh, it won't work from ~/.bazaar/plugins | 16:51 |
| jelmer | no, subvertpy isn't a plugin | 16:51 |
| jelmer | you need to install it | 16:51 |
| luke-jr | it's not packaged | 16:52 |
| luke-jr | any reason it won't work if I put it inside plugins/svn/ like it used to be? | 16:52 |
| jelmer | I removed the support in bzr-svn for supporting that - it extended the python system path, slowing imports down | 16:53 |
| luke-jr | sigh | 16:54 |
| jelmer | Lo-lan-do, is there any chance of having a newer bzr installed on alioth? | 16:57 |
| luke-jr | ok, reverted that | 16:57 |
| luke-jr | Unable to load plugin 'svn'. It requested API version (1, 11, 0) of module <module 'bzrlib' from '/usr/lib/python2.5/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 7, 0), and the maximum is (1, 10, 0) | 16:58 |
| luke-jr | :/ | 16:58 |
| jelmer | luke-jr, yes, you need at least bzr 1.11 | 16:58 |
| luke-jr | sigh | 16:58 |
| jelmer | luke-jr: alternatively, you can wait for bzr 1.12 and bzr-svn 0.5.0 to be released/packaged | 16:59 |
| luke-jr | … | 16:59 |
| luke-jr | if I wait for those do I get copy support? ;) | 16:59 |
| jelmer | (-: | 17:00 |
| luke-jr | it's a pain to push, svn checkout, svn commit, pull, all just to make a copy :/ | 17:00 |
| luke-jr | File "/home/luke-jr/.bazaar/plugins/svn/__init__.py", line 159, in lazy_register_optimizers | 17:01 |
| luke-jr | if _optimizers_registered: | 17:01 |
| luke-jr | NameError: global name '_optimizers_registered' is not defined | 17:01 |
| luke-jr | (this is in my bzr-svn test stuff, branch of a file:/// URI | 17:02 |
| fullermd | Man, I hate trying to read diff when a lot of binary files are involved :( | 17:04 |
| jelmer | luke-jr, one sec | 17:04 |
| jelmer | luke-jr, that's caused by my ad-hoc fixes for you earlier | 17:04 |
| luke-jr | heh | 17:05 |
| Lo-lan-do | jelmer: I'm fine with backports in general, but I'm a bit iffy about using stuff from experimental on etch. | 17:05 |
| jelmer | luke-jr, please try again | 17:06 |
| luke-jr | jelmer: fwiw, that error exists even with a regular svn+http thing | 17:07 |
| jelmer | luke-jr, sorry, forgot to push. pushing now | 17:07 |
| jelmer | luke-jr, yeah, it was just a typo I introduced | 17:08 |
| jelmer | Lo-lan-do, I can upload to backports if that helps | 17:08 |
| jelmer | luke-jr, r2412 | 17:08 |
| luke-jr | ok, it's trying now | 17:09 |
| luke-jr | jelmer: so is there plan for per-file revisioned metadata for bzr? | 17:10 |
| luke-jr | or perhaps more appropriate for copy-simulation would be per-file unrevisioned metadata, but that's easily simulated by not changing it ;) | 17:11 |
| jelmer | luke-jr: there already is per-file revision metadata (e.g. name, executable bit). There are no plans for per-file custom revision metadata. | 17:11 |
| luke-jr | i c | 17:12 |
| luke-jr | so how would you store extended attributes? ;) | 17:12 |
| luke-jr | jelmer: branch successful | 17:14 |
| luke-jr | now if only copies worked, I could drop the constant VPN link ;) | 17:15 |
| jelmer | heh | 17:15 |
| beuno | deos anyone know hot so use bzr+ssh in a different port? | 17:20 |
| pickscrape | Does anyone have any idea when bzrtools 1.11 will make it into the PPA? | 17:21 |
| fullermd | beuno: bzr+ssh://foo:12345/some/path/ ? | 17:21 |
| pickscrape | beuno: is what fullermd said doesn't work, could ~/.ssh/config help at all? | 17:22 |
| pickscrape | s/is/if/ | 17:22 |
| Lo-lan-do | jelmer: That would be nice, yes. | 17:22 |
| beuno | fullermd, ay... thanks | 17:25 |
| aboSamoor | HI, my bandwidth is very bad and it disconnects frequently I got this message after breaking a push process "If you're sure that it's not being modified, use bzr break-lock lp-46717904:///~rmyeid/+junk/code/.bzr/branch/lock" | 17:26 |
| fullermd | (in checking it myself, I discover that ssh doesn't die very quickly if you point it at a SMTP-speaking port :P) | 17:26 |
| Peng_ | aboSamoor: "bzr break-lock lp:~rmyeid/+junk/code"? | 17:32 |
| === bac_lunch is now known as bac | ||
| aboSamoor | Peng_: Thanks very much. so why the message add number to the lp ? | 17:51 |
| garyvdm | aboSamoor: It's logged as bug 250451 | 18:05 |
| ubottu | Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/250451/+text) | 18:05 |
| garyvdm | https://bugs.launchpad.net/bzr/+bug/250451 | 18:05 |
| ubottu | Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [High,Confirmed] | 18:05 |
| === dereine[OFF] is now known as dereine | ||
| === _thumper_ is now known as thumper | ||
| garyvdm | Hi - Is there a way to increase the allowed number of Concurrent Requests for the smart protocol? | 19:04 |
| garyvdm | Let me explain why: In qbzr I'm now displaying the transport activity. When the transport activity gets updated, I call processEvents, which causes the QT event loop to cycle. | 19:13 |
| garyvdm | I was testing this with Andrews branch that displays the transport activity for the smart protocol. (http://people.ubuntu.com/~andrew/bzr/traffic-smart/) | 19:15 |
| garyvdm | So if qbzr is loading somthing, and you do something else though the user interface that causes something else to be loaded, to get a TooManyConcurrentRequests error. | 19:17 |
| asabil | anyone knows the API to use in order to copy an old revision tree into a new working tree ? | 19:27 |
| jelmer | asabil: rebase has a function to do a complete revert | 19:31 |
| jelmer | asabil, you can do a "set_revision()" call followed by that call | 19:31 |
| asabil | jelmer: maybe my question wasn't clear | 19:31 |
| asabil | as I said earlier I am working on filter-branch for bzr | 19:32 |
| asabil | and I just want to create a new branch based on an old branch with no transform operation for now | 19:32 |
| asabil | I just don't know how to recreate new commits identical to the ones from the source branch | 19:33 |
| asabil | but with a different revid | 19:33 |
| james_w | asabil: revert is the correct operation I guess | 19:33 |
| james_w | revert is "set the working tree to be the same as this revision tree" | 19:33 |
| asabil | hmm ok | 19:34 |
| asabil | so I should use the code from bzr-rebase ? | 19:34 |
| james_w | give it a go | 19:35 |
| asabil | oki thanks for the help | 19:35 |
| james_w | or just lookup what the revert builtin does | 19:35 |
| asabil | ok thanks | 19:36 |
| jelmer | asabil: I would imagine bzr-rebase and bzr-filter-branch share a lot of code, I think it makes sense to have them in the same plugin | 19:40 |
| jelmer | (maybe we'll need to rename that plugin) | 19:40 |
| asabil | jelmer: yes they will, but I am still experimenting for now :) | 19:40 |
| asabil | I would be really happy to add filtering to bzr-rebase | 19:40 |
| asabil | I am not very familiar with the bzrlib APIs | 19:41 |
| fullermd | How are you defining what to adjust in the filtering process? | 19:42 |
| asabil | it is not really filtering | 19:43 |
| fullermd | (from a user perspective, I mean) | 19:43 |
| asabil | but more like copy-and-modify | 19:43 |
| asabil | for now I would like to be able to apply a filter on commit messages to rewrite them | 19:43 |
| asabil | fullermd: not sure if I answered your question :) | 19:44 |
| fullermd | Not exactly, no. I mean "How do I as a user of filter-branch specify what to change?" | 19:44 |
| asabil | I will probably go for the same solution as git-filter-branch | 19:46 |
| asabil | something like | 19:46 |
| asabil | bzr filter-branch source destination --message-filter="sed -i -e 's/hello//'" | 19:46 |
| fullermd | Ah. | 19:46 |
| asabil | it is not optimal, but still, it will be useful enough for most users I guess | 19:47 |
| fullermd | I have this occasionally-recurring idyll that it would be kinda fun (in my CFT of course) to try designing a somewhat VCS-agnostic grammar for describing history rewrites like that. | 19:48 |
| asabil | hmm, that would be a good idea indeed | 19:50 |
| fullermd | (at least general enough to handle the general class of DAG-history VCSen, anyway) | 19:51 |
| fullermd | Yah. Could be pretty useful. And I think it'd be a fun thing to play with. | 19:53 |
| fullermd | I currently have it scheduled to do after I deal with some more urgent things on my todo. | 19:54 |
| fullermd | Which means it's currently scheduled for spring 2075... | 19:54 |
| asabil | rofl | 19:54 |
| bialix | you're immortal I guess | 19:55 |
| fullermd | I am indeed. | 19:56 |
| fullermd | So far, so good. | 19:56 |
| bialix | anybody saw LarstiQ here today? | 19:57 |
| fullermd | 6 hours ago or so... | 19:57 |
| bialix | heh | 19:57 |
| bialix | fullermd: did you made bzrtools package for FreeBSD? | 19:58 |
| fullermd | I didn't make it, but I'm the current maintainer of the port, yah. | 19:58 |
| fullermd | (packages are auto-built from the port; I don't have any direct control over that) | 19:59 |
| bialix | yeah, thank you. I know you're take care about bzr @ FreeBSD | 19:59 |
| bialix | so have the luxury to use bzr at my hosting | 19:59 |
| bialix | I have the luxury | 19:59 |
| fullermd | It's 'cuz I'm too impatient to wait for someone else to get around to updating it when new releases come out ;) | 20:00 |
| bialix | can you suggest me the link for bzrtools @ FreeBSD? so I can nag my hoster to install it | 20:00 |
| fullermd | It's in ports/devel/bzrtools/, next to bzr at devel/bazaar-ng/ | 20:01 |
| bialix | oh, indeed. I'm not very smart | 20:02 |
| bialix | great | 20:02 |
| fullermd | The bug thread earlier today about the package depends in Ubuntu did make me think about whether the graphviz depend should be on by default... | 20:03 |
| fullermd | Maybe I'll flip that next time there's a release. | 20:04 |
| bialix | what's the filter-branch discussed here earlier? | 20:08 |
| bialix | asabil? | 20:10 |
| asabil | james_w: using tree.revert complains about unversioned files | 20:11 |
| asabil | bialix: a small proof of concept plugin, to be able to generate new branches from an old branch | 20:11 |
| asabil | by applying transforms | 20:11 |
| bialix | asabil: does your code public already? | 20:11 |
| asabil | (changing commit message, removing files ...) | 20:11 |
| bialix | I'm interesting in such plugin | 20:11 |
| asabil | no it is not working at all yet | 20:12 |
| jelmer | asabil, Did you try the complete_revert () from rebase? | 20:12 |
| asabil | I am still diving into the bzrlib APIs | 20:12 |
| jelmer | fullermd, I've already done that for Debian | 20:12 |
| asabil | jelmer: I am not sure how to use it | 20:12 |
| bialix | I need the way to factor some subdir out of the branch | 20:12 |
| jelmer | fullermd, since it was pulling X libraries on servers, etc | 20:12 |
| asabil | why does it take newparents as a parameter ? | 20:12 |
| bialix | but instead of split I'd like to copy only relevant history | 20:13 |
| bialix | asabil: does your plugin will allow this? | 20:13 |
| asabil | jelmer: for revision 1, the parents is [] | 20:13 |
| asabil | bialix: it is inexistant yet, I will release it asap | 20:13 |
| fullermd | jelmer: Yah, that was what I was reading ;) | 20:13 |
| bialix | yep, I understand. I'm just trying to understand what it will an what it won't | 20:14 |
| asabil | bialix: it is more of the other way around, but it will sort of allow you to do such things | 20:14 |
| jelmer | asabil, it resets to the contents of parents[0] and sets the other parents as pending merges | 20:14 |
| asabil | jelmer: and how to handle the 1st commit ? | 20:15 |
| jelmer | asabil, the empty tree you mean? | 20:15 |
| jelmer | asabil, [NULL_REVISION] | 20:15 |
| asabil | doesn't work | 20:15 |
| asabil | ERROR: Reserved revision-id {null:} | 20:16 |
| jelmer | oh, that would need special casing then I guess | 20:16 |
| jelmer | revision_tree() ? | 20:17 |
| asabil | jelmer: ok I special cased it and it does work :) | 20:18 |
| asabil | thanks a lot | 20:18 |
| asabil | I will just need to make the tree.commit () shut up | 20:18 |
| asabil | and it will be awesome | 20:18 |
| jelmer | asabil, any chance you can send a patch for that to bzr-rebase? | 20:18 |
| asabil | thanks a lot :D | 20:18 |
| LarstiQ | bialix: heya | 20:19 |
| asabil | jelmer: the special casing for complete_revert ? | 20:19 |
| bialix | heya! | 20:19 |
| jelmer | asabil, yeah | 20:19 |
| jelmer | hey LarstiQ | 20:19 |
| asabil | yes sure, will do | 20:19 |
| asabil | I just have to run right now | 20:19 |
| jelmer | ooh, LarstiQ and bialix here at the same time | 20:19 |
| asabil | will work on it this evening | 20:19 |
| asabil | ttyl | 20:19 |
| jelmer | asabil, thanks! | 20:19 |
| * LarstiQ starts up his mail client | 20:19 | |
| bialix | asabil: I've read help on git-filter-branch | 20:19 |
| LarstiQ | bialix: did you get my mail in the end? | 20:19 |
| bialix | yes, this morning | 20:20 |
| LarstiQ | cool, I wasn't sure it would actually be delivered | 20:20 |
| bialix | --subdirectory-filter <directory> -- that's what I need for scmproj | 20:20 |
| bialix | why not? | 20:20 |
| bialix | jelmer: btw, the text from ukr.net was in the Russian actually. but there is very small difference | 20:21 |
| jelmer | bialix, ah, sorry | 20:21 |
| bialix | brrrr, why you said sorry? | 20:21 |
| LarstiQ | bialix: and got your reply, thanks | 20:21 |
| bialix | LarstiQ: I'm very interesting to know about nested-by-reference | 20:22 |
| bialix | how the reference is stored? can you nest already nested trees? | 20:23 |
| jelmer | bialix: In case I had offended by confusing the two. | 20:23 |
| bialix | oh, no | 20:23 |
| bialix | nonono | 20:23 |
| bialix | no offence | 20:23 |
| jelmer | ok :-) | 20:24 |
| bialix | actually my native language is Russian | 20:24 |
| nua | anyone recognise this error: "bzr: ERROR: Server sent an unexpected error: ('error', "invalid literal for int() with base 10: 'None'")" ?? | 20:24 |
| LarstiQ | bialix: I have to page in the knowledge of how this works exactly again | 20:24 |
| bialix | if this possible, please | 20:25 |
| bialix | am I understand correctly that nested-by-values are stored in the parent dirstate? | 20:25 |
| bialix | dirstate of child tree -> parent dirstate | 20:26 |
| LarstiQ | iirc, nested by value includes the file graph of the child in the parent's graph | 20:26 |
| LarstiQ | so that would get into the dirstate, yes | 20:27 |
| bialix | so the graph is recalculated? | 20:27 |
| LarstiQ | but this is all airi, too long not looking at it | 20:27 |
| LarstiQ | bialix: the join and split commands should be in bzr core for a while now, I don't think that code is too different | 20:27 |
| bialix | may be I'll try to describe my problem wuth scmproj, so universe supermind can suggest something? | 20:28 |
| bialix | with | 20:28 |
| * LarstiQ nods at bialix | 20:28 | |
| bialix | scmproj tries to operate with "project" as set of branches | 20:28 |
| bialix | it's like a cheap emulation of nested trees | 20:29 |
| bialix | hi amanica! | 20:29 |
| AmanicA | hi guy | 20:29 |
| bialix | but I'd like to put some smaller project into other bigger megaproject | 20:30 |
| bialix | and call it subproject | 20:30 |
| bialix | but what if my subproject also has inside another subproject? | 20:30 |
| AmanicA | (bailix are you talking to me or did I join a conversation halfway?) | 20:31 |
| bialix | I've thought idea or implementation of nested tree "by reference" will give me some klue | 20:31 |
| bialix | clue, sorry | 20:31 |
| bialix | I'm talking to LarstiQ, and to universe supermind here | 20:32 |
| AmanicA | cool :) | 20:32 |
| LarstiQ | bialix: nested-trees has a CompositeTree, that allows for a nesting of subtrees more than one level deep, which you seem to be running into? | 20:32 |
| * LarstiQ believes lifeless wasn't too fond of that solution | 20:32 | |
| bialix | I guess so | 20:32 |
| bialix | my subprojects always will be nested by reference, IIUC | 20:33 |
| LarstiQ | yeah, that makes sense | 20:33 |
| bialix | there is another nasty problem I can't figure out yet: recursion | 20:33 |
| LarstiQ | oof | 20:34 |
| Lo-lan-do | jelmer, Jc2k: I've been wondering about the colocated branches and bzr-git, thinking about the possibility of interacting with several git branches from bzr. | 20:34 |
| LarstiQ | bialix: is it needed? If not, it should be possible to disallow it? | 20:34 |
| bialix | LarstiQ: I guees bzr can detect recursion by TREE_ROOT id? | 20:35 |
| bialix | LarstiQ: what's exactly? to dissalow | 20:35 |
| Lo-lan-do | Assuming push-to-git is completed soon, could one use branch renames in git to interact with various git branches in the same git repo? | 20:35 |
| bialix | disallow | 20:35 |
| bialix | I can disallow nested subprojects, but I think it will be bad | 20:36 |
| Jc2k | Lo-lan-do: i think so.. as a temporary hack until we can properly do colocated branches.. | 20:37 |
| bialix | LarstiQ: CompositeTree implementation in your branch only? or in bzr.dev too? | 20:37 |
| LarstiQ | bialix: in my branch only | 20:37 |
| LarstiQ | bialix: there are still bugs in there | 20:37 |
| LarstiQ | bialix: like, moving a file across subtree boundaries | 20:38 |
| bialix | that's nightnare problem | 20:38 |
| Lo-lan-do | Jc2k: That's cool, since we could just script something that renames each git branch to master, then push/pull into it, then rename it back. | 20:38 |
| bialix | nightmare | 20:38 |
| bialix | LarstiQ: how the branches are changed after join? | 20:38 |
| LarstiQ | bialix: I meant disallowing recursion, at add time you should be able to figure out, with TREE_ROOT, wether you're looping, and if so, don't add it | 20:39 |
| LarstiQ | bialix: join and split are for by-value | 20:39 |
| bialix | LarstiQ: it's not my case | 20:39 |
| * LarstiQ nods | 20:39 | |
| bialix | bzr join has option --by-reference | 20:39 |
| LarstiQ | ah right | 20:40 |
| * LarstiQ is more familiar with the bzrlib side of things | 20:40 | |
| bialix | no, sorry, just --reference | 20:40 |
| LarstiQ | bialix: and as I said, it has been a while, but I would be very happy to get it back on track | 20:40 |
| LarstiQ | bialix: you're providing excellent stimulation to work on it :) | 20:40 |
| Jc2k | Lo-lan-do: well people desperate enough could, i dont think we'd want to ship anything quite so.. unique! :D | 20:40 |
| bialix | LarstiQ: it will be great | 20:40 |
| LarstiQ | bialix: so thank you for that | 20:40 |
| bialix | me? | 20:41 |
| Lo-lan-do | Jc2k: The point is to allow me and the git guy to work on the same project without the SVN wart in the middle. | 20:41 |
| LarstiQ | bialix: yes, thank you for motivating me | 20:41 |
| Jc2k | Lo-lan-do: yeah, it would be ideal for you | 20:42 |
| * bialix still don't understand how the nested tree will work under the cover | 20:42 | |
| AmanicA | bialix: so is this recursion problem about finding the parent project? | 20:42 |
| bialix | yes | 20:42 |
| LarstiQ | bialix: the most relevant code is bzrlib/composite_tree.py (and bzrlib/tests/test_composite_tree.py) btw | 20:42 |
| lifeless | moin | 20:42 |
| * bialix going to run bzr branch | 20:42 | |
| lifeless | Jc2k: you had questions for me | 20:43 |
| LarstiQ | bialix: adding a subtree: tree.add_reference(subtree) | 20:43 |
| lifeless | LarstiQ: I was fine with the solution as a stepping stone; but loading all the trees always doesn't scal | 20:43 |
| AmanicA | bialix: why cant we just split /x/y/z into ('x','y','z') and then chop off one, check, repeat? | 20:43 |
| LarstiQ | bialix: iirc, some of the semantics were still up in the air. One thing jelmer wants for example is ala svn:externals, "give me HEAD of that library over there" | 20:44 |
| LarstiQ | lifeless: ok. And agreed. | 20:44 |
| bialix | AmanicA: umm? | 20:44 |
| AmanicA | bialix we can use path.split(/x/y/z) to get ('x','y','z') | 20:45 |
| Jc2k | lifeless: oooh. umm. for one of them, see the bzr-hookless-email thread on ML | 20:45 |
| bialix | LarstiQ: my plugin now working exactly this way | 20:46 |
| AmanicA | bialix: then we can move up one by one and check if it has a .scmproj | 20:46 |
| lifeless | Jc2k: I saw; I'm curious why smart server hooks didn't do what you need - but hookless polish is nice too | 20:46 |
| bialix | amanica: let's imagine you already have some megaproject | 20:46 |
| bialix | amanica: and then you add it to another megaproject as subproject | 20:47 |
| bialix | we need to catch recursion at fetch/checkout operations | 20:47 |
| Jc2k | lifeless: i presumed that doing a lot of stuff in smart server hooks would mean more time until the user at the end of bzr push could resume hacking, and thats why hookless existed | 20:48 |
| AmanicA | bialix: so that they don't contain each other.. | 20:48 |
| bialix | amanica: actually, I'd like to keep all metainfo about subprojects (even nested) inside parent control dir | 20:48 |
| lifeless | Jc2k: hookless exists because smart server hooks are recent | 20:48 |
| lifeless | brb | 20:49 |
| LarstiQ | and because not all sites run the smart server | 20:49 |
| AmanicA | bialix: so you don't want to assume that all subprojects are in a subdir of its parent project? | 20:49 |
| bialix | LarstiQ: your branch is indeed old! it gave me upgrade warning | 20:49 |
| LarstiQ | bialix: yes :( | 20:49 |
| * bialix still branching... | 20:50 | |
| LarstiQ | bialix: I've started to merge bzr.dev back in | 20:50 |
| Jc2k | lifeless: so there are hooks and smart server hooks..? | 20:50 |
| LarstiQ | bialix: I'll upgrade the branch format when I push that | 20:50 |
| bialix | amanica: we need the way to mark subprojects as such | 20:50 |
| AmanicA | bialix: then we so while we walk the subproject tree, we just keep a cache of visited projects, and don't add them again. | 20:51 |
| bialix | either we keep their own .scmproj all around (a-la .svn) or we keep everything inside parent .scmproj | 20:51 |
| bialix | AmanicA: but how we detect visited projects? | 20:51 |
| * bialix guess scmproj should force usage of rich-roots | 20:52 | |
| AmanicA | bialix: I think each project/subproject should have its own .scmproj | 20:52 |
| * Lo-lan-do guesses rich-roots really should be enabled by default | 20:52 | |
| * bialix too | 20:52 | |
| bialix | but it's the trap door, and this is pain in the ass | 20:53 |
| * LarstiQ would like to have rich-root default, or a way to get data from rich-root to non-rich-root | 20:53 | |
| LarstiQ | bialix: yeah :/ | 20:53 |
| * bialix too | 20:53 | |
| Lo-lan-do | Well, it depends on what there is to gain on the older side of the trapdoor. | 20:53 |
| * bialix guesses fast-import can help here | 20:54 | |
| AmanicA | bialix: I don't know where the proj tree traversal code is, I can play with it I might understand better | 20:54 |
| fullermd | I think the last concensus was that the fence would be jumped with the repo format with new inventories, since that require rewriting $LOTS anyway. | 20:54 |
| bialix | AmanicA: there is no traversal code yet | 20:54 |
| bialix | it should be in the run_actions loop | 20:55 |
| bialix | as the resursive call | 20:55 |
| bialix | I really need to figure out how to store subproj info first | 20:55 |
| kfogel | So what is "rich-root"? Doing a search for it on bazaar-vcs.org turns up two links, neither of which explains it. | 20:55 |
| AmanicA | bialix: so when/if you actually run into this, call me up and we can figure it out. I'm sure we will be able to. | 20:55 |
| bialix | Anybody wanna throw in me rotten tomatos? | 20:55 |
| bialix | well, we are already here | 20:56 |
| lifeless | Jc2k: smart server hooks -> hooks fired on the server, same interface, same registration, just needs a client that knows to tell the server 'run now' | 20:56 |
| fullermd | A root that engages in oppression and exploitation of the proletariat, of course. | 20:56 |
| bialix | I'd like to keep the subprojects info in the .scmproj/subproj/<NAME> | 20:56 |
| AmanicA | :) | 20:56 |
| bialix | fullermd: LOL | 20:57 |
| bialix | I'm born in the USSR | 20:57 |
| lifeless | kfogel: the root node was treated specially in early bzr, which we think was a mistake | 20:57 |
| bialix | I've born | 20:57 |
| LarstiQ | kfogel: rich-root formats store an extra bit of metadata, namely the fileid of the tree root | 20:57 |
| AmanicA | bialix: just because of the recursion problem? | 20:57 |
| lifeless | kfogel: rich-roots correct that and have them treated normally. | 20:57 |
| bialix | I guess svn has the ID too | 20:57 |
| lifeless | kfogel: in principle the root of a rich root could be a file or symlink even :P. in PRINCIPLE. | 20:58 |
| lifeless | brb fooding | 20:58 |
| bialix | AmanicA: no, just to make the entire project looks flat | 20:58 |
| kfogel | lifeless, LarstiQ: um. Thank you. But, as a user, what does "rich-root" mean to me? :-) | 20:58 |
| Jc2k | lifeless: right. and if you wanted to do stuff for each revision that just got inserted, it would block the user that is pushing until it finishes? | 20:59 |
| AmanicA | bialix: I'm hoping that we can avoid it, but its your call. | 20:59 |
| LarstiQ | kfogel: pain. | 20:59 |
| AmanicA | ditto | 20:59 |
| bialix | WDYM: it's my call? | 20:59 |
| LarstiQ | kfogel: a concrete problem with non rich-root formats, is that if you want to do nested-trees, you have two entries that have the same fileid, 'TREE_ROOT' | 20:59 |
| LarstiQ | kfogel: so with rich-root, each would have their own unique id | 21:00 |
| AmanicA | bialix: its your decision | 21:00 |
| bialix | you don't like it? why? | 21:00 |
| LarstiQ | kfogel: bzr-svn makes use of rich-roots (I believe because it can/wants to split and join trees) | 21:01 |
| fullermd | Another is that it means you can't do a root pivot, if bzr had a root pivot command. | 21:01 |
| AmanicA | bialix: I don't want the subproject info in the parent project's special dir | 21:01 |
| bialix | but we need to mark somehow subproject as such | 21:01 |
| bialix | how? | 21:01 |
| Lo-lan-do | LarstiQ: I thought it's because it stores additional metadata as properties of the root dir, but I might be talking nonsense. | 21:02 |
| AmanicA | bialix: we can have a section in project.cnf | 21:02 |
| AmanicA | .cfg | 21:02 |
| bialix | for backlinks? | 21:02 |
| bialix | it's bad idea | 21:02 |
| bialix | we version control this file | 21:03 |
| bialix | so we need to use local config | 21:03 |
| AmanicA | bialix: I think its good | 21:03 |
| LarstiQ | Lo-lan-do: quite posisble, I'm a bit detached from the actual bzr-svn usage | 21:03 |
| LarstiQ | kfogel: now, all this is fine and good. | 21:03 |
| AmanicA | to version what subprojects are part of the superproject | 21:03 |
| bialix | but then you'll get subproject as standalone project and this backlink will be there forever? | 21:03 |
| LarstiQ | kfogel: except, non rich-root formats can't represent this information, so when someone branches of a non-rich root, then upgrades, their work can no longer flow back. | 21:04 |
| LarstiQ | kfogel: which I think is a major PITA | 21:04 |
| Lo-lan-do | LarstiQ: I'm trying to get detached too, but I'm stuck with it until bzr-git gets push support. | 21:04 |
| bialix | AmanicA: well, we already should explicitly point at subproject in the megaproject config | 21:04 |
| etenil | Hello | 21:05 |
| LarstiQ | etenil: hello | 21:05 |
| AmanicA | bialix: I mean the magaproject needs to know of its subprjects, not backlinking it | 21:05 |
| kfogel | LarstiQ: I started half understanding that, toward the end... | 21:05 |
| bialix | AmanicA: look please at the bug https://bugs.launchpad.net/bzr-scmproj/+bug/313150 | 21:06 |
| ubottu | Launchpad bug 313150 in bzr-scmproj "project comands for local project checkout should be possible to run from subdir" [Medium,Confirmed] | 21:06 |
| AmanicA | ok | 21:06 |
| kfogel | LarstiQ: (not trying to play-act the part of stubbornly ignorant user -- I really am struggling to understand when/how to use/care about rich-root.) | 21:06 |
| etenil | I'm using bzr with tortoise-bzr for work but a lot of features are missing. What GUI is the most advanced for windows currently? | 21:06 |
| * LarstiQ nods at kfogel | 21:06 | |
| bialix | etenil: if you need standalone GUI -- bzr-gtk then | 21:07 |
| LarstiQ | kfogel: right now, I'd say, stay away from them, unless you know you need them. | 21:07 |
| bialix | if you can live with command-line -- QBzr then | 21:07 |
| etenil | bialix: even for windows? | 21:07 |
| AmanicA | bialix didnt we discus having a --me-only option? | 21:07 |
| pickscrape | Does anyone know when bzrtools 1.11 will hit the PPA? | 21:07 |
| bialix | etenil: bzr-gtk? yes | 21:07 |
| AmanicA | (or something like that) | 21:07 |
| bialix | etenil: for bzr-gtk see http://bazaar-vcs.org/WindowsInstall | 21:08 |
| etenil | bialix: thanks a lot, i'll give it a try. Some of my colleagues are allergic to the command line | 21:08 |
| bialix | etenil: I'm very happy with FAR | 21:08 |
| LarstiQ | etenil: I'd go with QBzr (which tortoise uses under the hood too) | 21:08 |
| bialix | it's more than just command-line | 21:08 |
| LarstiQ | etenil: what features are you missing? | 21:08 |
| bialix | AmanicA: --me-only? | 21:08 |
| bialix | I don't remember | 21:09 |
| AmanicA | bialix: some option to say that we run command for this subproject only | 21:09 |
| bialix | etenil: what is missing for you in TBZR? | 21:09 |
| etenil | LarstiQ: conflict resolution, update to a previous revision | 21:10 |
| bialix | AmanicA: yes, it's make sense | 21:10 |
| etenil | revert only a file | 21:10 |
| etenil | this kind of thing | 21:10 |
| AmanicA | bialix: that bug is important for me too | 21:10 |
| AmanicA | (to get fixed) | 21:10 |
| bialix | AmanicA: this bug is main confusion for me and subprojects | 21:11 |
| bialix | if we put subprojects as is we need the way to somehow mark them as subprojects | 21:11 |
| bialix | but then one can just copy the subproject by hand and things will be broken | 21:12 |
| bialix | this is *the* problem | 21:12 |
| bialix | LarstiQ: may I ask you to look at my plugin in the near future and say me what you think? | 21:13 |
| LarstiQ | bialix: yes | 21:13 |
| bialix | I need more feedback | 21:13 |
| LarstiQ | bialix: my day off is wednesday, I have some prior commitments, but I intend to spend time on nested-trees and scmproj both tomorrow | 21:14 |
| bialix | one guy call it "clunky". but I don't understand what it means | 21:14 |
| LarstiQ | bialix: other than that, I will be on vacation in Finland 10-18 february, so also more time for these things | 21:14 |
| bialix | mmmm, vacation! | 21:14 |
| LarstiQ | bialix: clunky is similar to cumbersome | 21:14 |
| LarstiQ | (visiting my girlfriend actually) | 21:14 |
| bialix | you're happy | 21:14 |
| bialix | LarstiQ: but what it means exactly? what's wrong? | 21:16 |
| bialix | it's the only a word | 21:16 |
| LarstiQ | bialix: I'm also a non-native, let me look up how to describe this differently :) | 21:17 |
| bialix | no | 21:17 |
| bialix | I mean: this means that guy don;t like something | 21:17 |
| bialix | but I need to know what exactly | 21:18 |
| bialix | something in the design? or in the implementation? | 21:18 |
| LarstiQ | bialix: yes, it is a feeling/impression that it is not elegant | 21:18 |
| bialix | or main idea is clunky? | 21:18 |
| LarstiQ | ah, that I don't know | 21:18 |
| LarstiQ | is his comment public? | 21:18 |
| LarstiQ | 'clunky' by itself isn't very useful feedback | 21:19 |
| bialix | yep | 21:19 |
| bialix | I need more helpful feedback | 21:19 |
| bialix | even negative one | 21:19 |
| * LarstiQ nods | 21:22 | |
| LarstiQ | bialix: I'm going to try to apply it to some of my branches from work tomorrow. | 21:23 |
| LarstiQ | and will report my experience | 21:23 |
| lifeless | kfogel: rich root means 'a one way upgrade that propogates to all users of a project' | 21:23 |
| lifeless | kfogel: thats about it | 21:23 |
| bialix | oh, your branch is cloned | 21:23 |
| bialix | LarstiQ: I hope we will have better scmproj implementation in the Feb | 21:24 |
| * garyvdm wishes he could use python 3.0's nonlocal feature. | 21:26 | |
| LarstiQ | bialix: I started reading the current docs/devel.text and docs/howto.txt, is that knowledge going to get obsoleted? | 21:26 |
| bialix | docs/devel.txt: we are working on new project.cfg format and new layout of .scmproj | 21:27 |
| bialix | some new docs available at http://bazaar-vcs.org/ScmProj/ (under the horizontal bar) | 21:28 |
| LarstiQ | bialix: k | 21:30 |
| kfogel | lifeless: one thing that it took me a while to get through my head: bzr's storage format and transport format are intertwingled. That is, in many systems the format on the server side can be independent of the format on the client side. But in bzr, the client gets whatever the server has, and (apparently?) doesn't do automatic downgrade/conversion if client is a lower version than server? | 21:30 |
| bialix | LarstiQ: main idea of new config: everything is optional | 21:30 |
| Lo-lan-do | kfogel: There's a question of losing information if the client isn't able to represent it. | 21:31 |
| lifeless | kfogel: well, the only system I know of that is truely seperate is hg; git uses its local pack format, cvs uses its delta format etc | 21:31 |
| lifeless | kfogel: anyhow, many operations in bzr use a VFS rather than smart verbs, mainly due to 'TODO'. (Clearly working over plain http is all VFS based, as is local disk, so diminishing returns apply to structuring those operations that also perform well on their own) | 21:32 |
| kfogel | lifeless: no, CVS's server-side storage is actually independent of the client (they just look similar); SVN is also independent. | 21:33 |
| kfogel | Obviously, any time a server sends something a client can't represent, there's going to be a problem :-). | 21:33 |
| lifeless | kfogel: they may be defined as being independent; having written a CVS parser though, I am pretty sure they are the same :) | 21:33 |
| kfogel | lifeless: ? Server just sends diff format to the client. The diffs are not actually the same ones that appear in the RCS files, usually. | 21:34 |
| kfogel | (not that any of this matters for bzr, so maybe I should shut up :-) ) | 21:35 |
| lifeless | kfogel: depends on the verb you call, you can ask for the whole rcs file | 21:35 |
| lifeless | kfogel: IIRC - I'll dig it up if it really interests you | 21:35 |
| kfogel | no, it definitely does *not* interest me :-) | 21:35 |
| lifeless | kfogel: (its in cscvs's CVS module | 21:35 |
| * LarstiQ grins at kfogel | 21:35 | |
| * kfogel looking as uninterested as possible | 21:35 | |
| kfogel | lifeless: I believe you! :-) | 21:36 |
| lifeless | :P | 21:36 |
| lifeless | check up, I could well be wrong. I just don't think I am :) | 21:36 |
| LarstiQ | aaanyway | 21:37 |
| * LarstiQ goes home | 21:37 | |
| bialix | LarstiQ: bye | 21:38 |
| bialix | I'll read your code, hope will have more specific question tomorrow | 21:39 |
| LarstiQ | bialix: most of it is still Aaron's code, I didn't actually do all that much | 21:41 |
| bialix | LarstiQ: where add_tree method lives? | 21:42 |
| fullermd | I think mtn's wire format is completely divorced from its storage as well. | 21:42 |
| LarstiQ | bialix: add_reference? | 21:43 |
| bialix | ah, yes | 21:44 |
| bialix | mu bad | 21:44 |
| lifeless | fullermd: opposite - its a merkle tree | 21:44 |
| lifeless | fullermd: so there is a canonical representation you need chained hashes all the way down - doing it without it being precalculated (e.g. your native format) -> expeeeensive | 21:45 |
| lifeless | mtn syncing is closer to bittorrent than anything else :) | 21:45 |
| fullermd | Well, I meant in the sense that it comes off disk, is converted to a different format, sent across the wire, converted to a different format, then blatted onto disk. | 21:48 |
| fullermd | It doesn't just stream all the bytes coming off the network into a file (or DB record), like git sending whole packs, or bzr doing its VFS thing. | 21:48 |
| fullermd | (at least, AIUI) | 21:48 |
| lifeless | well sure | 21:49 |
| lifeless | but bzr doesn't do that either in a manner of speaking :) | 21:49 |
| fullermd | Well, no. That's why it's not fast enough ;p | 21:49 |
| === rizitis_away is now known as rizitis | ||
| fullermd | Or alternately, it does too little to be real fast, and too much to be real independant of the far side format... | 21:51 |
| nua | Hi, trying to get someone set up on a shared repo and they are using windows. I want them to use bzr+ssh:// but they can't seem to log in and the ssh key they generated in putty me looks different to mine :S ...its all numbers only | 21:52 |
| lifeless | fullermd: my point is that independence is not about disk representation so much as how much of the stack you depend on to write a lookalike server. e.g. for git you need chained hashes to infinity. Same for hg and mtn. | 21:52 |
| nua | any help would be great :D | 21:52 |
| lifeless | nua: well, there is a faq about windows and ssh I think, on the bazaar-vcs.org website | 21:53 |
| nua | we've been following that :s, says nothing about the keys | 21:53 |
| bialix | nua: where you host your repo? at windows or linux? | 21:54 |
| fullermd | lifeless: OIC. That would be a somewhat different axis than occured to me in scanning my scrollback. | 21:55 |
| nua | bialix: linux | 21:56 |
| kfogel | Why does https://lists.ubuntu.com/archives/bazaar/2009q1/051589.html say "An embedded and charset-unspecified text was scrubbed..." instead of having the body of my message? | 21:56 |
| bialix | putty generate keys in its own format | 21:56 |
| bialix | nua: you need to convert it to linuc format | 21:56 |
| nua | bialix: ah ok, how do I do that? | 21:57 |
| lifeless | kfogel: not sure; ask a sysop? | 21:57 |
| bialix | puttygen has the menu option for this IIRC | 21:57 |
| kfogel | lifeless: ok, thx | 21:57 |
| bialix | nua: main menu -> conversion -> export oen ssh key | 21:59 |
| bialix | open ssh | 21:59 |
| bialix | why for open_branch hook is designed? what's use case? | 22:09 |
| lifeless | bialix: policy control for smart servers | 22:10 |
| bialix | can it be used for ACL? | 22:10 |
| lifeless | if you raise an exception the branch can't be opened, so yes. Though it might look a little ugly as-is | 22:11 |
| bialix | to prevent read/write access? | 22:11 |
| bialix | what is policy control then? | 22:12 |
| lifeless | currently just setting the stacking information | 22:15 |
| lifeless | but its wide open for extension if you have something you want it to do | 22:15 |
| bialix | I need access control | 22:18 |
| bialix | setting up ssh on windows is not funny | 22:19 |
| bialix | another way (as I understand) is using Apache | 22:19 |
| fullermd | With what assurance level? | 22:20 |
| bialix | I will be very happy to have built-in ACL support in bzr smart server | 22:20 |
| fullermd | I mean, as long as VFS support is enabled, any access control short of the hard root is pretty soft. | 22:20 |
| lifeless | bialix: once we get VFS disabled I too am interested in ACL's | 22:20 |
| lifeless | fullermd: write-ACL is easier | 22:20 |
| lifeless | fullermd: just prohibit writes until ACL check passed | 22:21 |
| fullermd | That would still only protect you at repo boundaries. | 22:21 |
| lifeless | fullermd: and outside that you're chrooted anyhow, and we shouldn't write to non repostuff at all with acl's on | 22:22 |
| fullermd | Right, but I mean as soon as you're OK'd to do anything in a given repo, you can pretty much to anything to anything in that repo. | 22:23 |
| bialix | kfogel: it's nice story: http://bazaar-vcs.org/Scenarios/PrivateShare :-D | 22:25 |
| kfogel | bialix: uh, please feel free to whip that one into shape :-) | 22:26 |
| bialix | I'm not native English speaker | 22:26 |
| kfogel | Hmmm, while we're at it, what is our commit email story? | 22:26 |
| kfogel | So far, all the systems I've seen for generating commit mails run on the individual developer's machine. | 22:26 |
| lifeless | kfogel: install bzr-email on the server, use bzr server and client 1.8 or newer (if I recall the version correctly) | 22:27 |
| kfogel | *nod* | 22:27 |
| Lo-lan-do | I thought there was one hook called on the server? | 22:27 |
| lifeless | Lo-lan-do: its the same hook | 22:27 |
| lifeless | Lo-lan-do: see the most recent bzr-email commit, I changed hooks and thus it works ;) | 22:28 |
| Lo-lan-do | Haven't started bzr-email so far, but will do at some point. | 22:28 |
| Lo-lan-do | Er, haven't started *using* it. | 22:28 |
| kfogel | lifeless: the real issue (not one we should try to solve now) is probably that there are two distinct concepts: a "checkpoint" and a "commit" (or a "commit" and a "merge", or something). What devs do with their local branches are usually checkpoints; when they pull or push a set of changes, the result is a merge, and (on the master branch) that's what should produce a so-called commit email, IMHO. | 22:28 |
| lifeless | kfogel: yes, thats what I describe does | 22:31 |
| lifeless | kfogel: though some projects want continual integration, others want stronger qa, etc etc | 22:32 |
| kfogel | lifeless: "that's what what I describe does"? (just checking that I'm parsing right) | 22:33 |
| lifeless | bzr-email on the server will trigger emails on push/uncommit/commit to the branches its set to notify on | 22:34 |
| kfogel | lifeless: so the comments near the top of https://savannah.gnu.org/support/index.php?106612 (comments #4, #5, #6, #7) are confused, and I should tell the Savannah admins that bzr-email does what we want? | 22:34 |
| lifeless | Jc2k: re blocking the user - 'maybe'. Some hooks want to block the user. Others want to be async; the hook interface specifies whether things are pre-or-post - pre should block, post shouldn't. | 22:35 |
| lifeless | reading | 22:35 |
| * bialix waves bye | 22:35 | |
| lifeless | ciao bialix | 22:35 |
| Jc2k | lifeless: so post hooks run after the bzr client has been and gone? | 22:36 |
| kfogel | lifeless: so if I push N commits into branch B, and bzr-email is set to trigger email, one email will go out, containing the cumulative diff of the N commits, not N diffs nor N emails, right? | 22:36 |
| lifeless | Jc2k: implementation vs interface :P | 22:37 |
| lifeless | Jc2k: I'm saying that having post hooks on the server run via e.g. dbus, or threads, or fork, is all permitted | 22:37 |
| lifeless | Jc2k: though ones that want to give feedback to the user naturally have to block the UI | 22:38 |
| Jc2k | right.. | 22:43 |
| lifeless | anyhow, like I said, hookless polish is nice | 22:44 |
| lifeless | for folk wanting to use e.g. sftp for hosting where server side hook firing is much harder | 22:44 |
| ronny | oh, heh - yay - i just figured how to exactly to deal with bzr in anyvc | 22:45 |
| Jc2k | in that case use case, reusing Branch.hooks is probably the right thing to do, even if the PostBranchTipChange behaviour is slightly different | 22:45 |
| Jc2k | (2 branch tip changes could become a single event) | 22:46 |
| lifeless | Jc2k: yeah, I don't really see any reason to have different interfaces | 22:46 |
| lifeless | unless things really are different | 22:47 |
| Jc2k | lifeless: yeah, it was only a worry if there was a use case for using this (out of process) instead of using the hooks in process. if i use Branch.hooks, the hook would happen in-process and out-of-process | 22:48 |
| Jc2k | but it sounds like you'd never want out-of-process (hookless) when you have the smart server | 22:48 |
| lifeless | Jc2k: there is a similar concern with client and server hooks | 22:48 |
| nua | my friend is trying to connect to a shared repository hosted on linux from his windows machine using tortoise-bzr and now we only get the following error: bzr: ERROR: Server sent an unexpected error: ('error', "invalid literal for int() with base 10: 'None'") | 22:49 |
| ollie | is there a way to do a cat of a specific file at a specific version? | 22:49 |
| lifeless | we want some things to run on the client, but not if the server will run *the same hook*; and the server has to have the plugin active to meet that check - its unsolved today :P | 22:49 |
| nua | the only way to fix it is to delete the repo, bzr init again and push from my machine | 22:49 |
| lifeless | ollie: bzr cat -r X path | 22:49 |
| ollie | lifeless: thanks :) | 22:49 |
| lifeless | beuno: please give me scroll bars back : http://bazaar.launchpad.net/~bzr/bzr-email/trunk/revision/39 | 22:50 |
| asabil | jelmer: http://pastebin.com/m6c2e8a0d | 22:51 |
| asabil | does this look good ? | 22:51 |
| jelmer | asabil, yeah | 22:52 |
| lifeless | spiv: ping | 22:54 |
| asabil | cool | 22:55 |
| lifeless | spiv: when did you activate post_change_branch_tip in the server? | 22:55 |
| Lo-lan-do | asabil: Is that the thing which will allow a rebasing onto an unrelated branch? | 22:55 |
| Lo-lan-do | Ah, no, sorry. Misread. | 22:56 |
| asabil | :) | 22:56 |
| * Lo-lan-do goes back to bickering about bzr-svn and bzr-git | 22:56 | |
| jelmer | uhoh | 22:57 |
| jelmer | should I be expecting a flood of bug reports? | 22:57 |
| Jc2k | jelmer: i have one, but i cant decide wither its bzr or bzr-git :P | 22:58 |
| Lo-lan-do | jelmer: Not yet, and I'll probably try to fiddle with stuff first. | 22:58 |
| Lo-lan-do | jelmer: I'm trying to bzr checkout (or branch) a copy of the old svn repo, and I get "NoSuchRevision: KnitPackRepository() has no revision foo" | 22:59 |
| Lo-lan-do | I suspect tricks with the repo's uuids. | 23:00 |
| Lo-lan-do | I'll probably end up doing svnadmin dump | filter.pl | svnadmin load to remove old bzr-related properties from the SVN repo, unless you're confident it won't help. | 23:00 |
| lifeless | Jc2k: file it on bzr-git then | 23:01 |
| Jc2k | lifeless: should repo.gather_stats work if there is no history yet? | 23:02 |
| jelmer | Lo-lan-do, no, that may very well help | 23:02 |
| jelmer | Lo-lan-do, is this the same repository you filed that debian bug about? | 23:02 |
| spiv | lifeless: hmm | 23:02 |
| jelmer | Jc2k, ah, that bug | 23:02 |
| jelmer | Jc2k, that's both a bzr and a bzr-git bug | 23:02 |
| Lo-lan-do | jelmer: I think it's another one obtained from the first one, or from the same source. | 23:02 |
| lifeless | spiv: its hard to tell; I think thats a bug | 23:03 |
| spiv | lifeless: probably 1.6, I think the Branch.set_last_revision_ex verb was the key | 23:03 |
| jelmer | Jc2k, bzr should be allowing a *completely* empty repository and bzr-git should be mentioning NULL_REVISION | 23:03 |
| Lo-lan-do | jelmer: svn://scm.fusionforge.org/fusionforge if you want to give it a try. | 23:03 |
| kfogel | lifeless: re my earlier question -- I'd like to pass along the answer to savannah admins: | 23:03 |
| kfogel | lifeless: so if I push N commits into branch B, and bzr-email is set to trigger email, one email will go out, containing the cumulative diff of the N commits, not N diffs nor N emails, right? | 23:03 |
| spiv | lifeless: (I think it had perhaps briefly worked during a 1.4 rc, but an apparently unrelated change had stopped the client from using the necessary verb, or something like that) | 23:04 |
| spiv | lifeless: I agree that that's a bug | 23:05 |
| lifeless | Jc2k: is inotify support in bzr-hookless trunk? | 23:05 |
| lifeless | kfogel: 1 email | 23:05 |
| lifeless | kfogel: it might be ugly, patches appreciated. | 23:06 |
| lifeless | s/might/probably is/ | 23:06 |
| Jc2k | lifeless: there is inotify in bzr-hookless-email and in my pluginified hookified version in lp:~johncarr/+junk/bzr-watcher | 23:07 |
| lifeless | Jc2k: cool | 23:07 |
| lifeless | Jc2k: https://savannah.gnu.org/support/index.php?106612 | 23:07 |
| kfogel | lifeless: great. That might even be a patch I can do, but at least this is enough for Savannah admins to get started. | 23:09 |
| Jc2k | lifeless: i was under the impression that hookless-email had had inotify for yonks | 23:09 |
| lifeless | Jc2k: my bad- your mail confused me :) | 23:10 |
| Jc2k | i fail at english :( | 23:10 |
| Jc2k | jelmer: if i want to implement dpush, GitRemoteBranch.dpull is where i should start? | 23:13 |
| Jc2k | jelmer: i've been thrown off by GitRemoteBranch.__init__ doing a fetch :\ | 23:13 |
| jelmer | Jc2k, I'm already working on dpush, to make sure we can push dulwich back into git.. | 23:13 |
| jelmer | I'm working on local though, not remote | 23:14 |
| Jc2k | ah | 23:14 |
| Jc2k | i'll leave it alone for now then | 23:15 |
| Jc2k | jelmer: does dpush rebase post-push to alter the revision ids? | 23:22 |
| jelmer | Jc2k, yes | 23:22 |
| Jc2k | jelmer: so if i hack on branch a, then branch that (as b) and hack on that, then dpush a.. i wont be able to merge b into a? | 23:22 |
| Jc2k | (unless i dpush first) | 23:23 |
| jelmer | Jc2k, yes | 23:24 |
| * Lo-lan-do finds the SVN::Dumpfilter module for Perl | 23:27 | |
| Lo-lan-do | That's probably going to make my life easier :-) | 23:27 |
| Lo-lan-do | But not tonight. /me → sleep | 23:28 |
| asabil | very quick and dirty, will probably get rewritten someday: lp:~asabil/+junk/bzr-filter-branch | 23:35 |
| === sabdfl1 is now known as sabdfl | ||
| asabil | ouch | 23:38 |
| asabil | it doesn't work :/ | 23:38 |
| igc | bbl | 23:38 |
| lifeless | jelmer: what did you need VirtualVersionedFiles.iter_lines_added_or_present_in_keys for ? | 23:47 |
| lifeless | jelmer: (it should _never_ get called unless you are claiming to have xml backend storage) | 23:47 |
| jelmer | lifeless, somebody had created a branch stacked on a svn branch | 23:47 |
| jelmer | lifeless, and was running "bzr stacked_branch new_branch" | 23:48 |
| lifeless | so bzr format stacked on svn format; branching from the bzr format | 23:50 |
| lifeless | hmm | 23:50 |
| jelmer | lifeless, it works with that function | 23:50 |
| lifeless | eep | 23:50 |
| lifeless | ok | 23:50 |
| lifeless | I'm not sure how you can tell what xml format to expose | 23:50 |
| lifeless | stacking is still _very_ format specific; I'm guessing you lie about your serialisation type? | 23:50 |
| jelmer | lifeless, I've just hardcoded it to a particular version at the moment | 23:50 |
| jelmer | lifeless, without that, I can't do versionedfiles *at all* | 23:51 |
| jelmer | as Repository.inventories and Repository.revisions use it | 23:51 |
| jelmer | lifeless, this is one of the reasons I've been asking about a more generic stacking API :-) | 23:52 |
| lifeless | jelmer: I think you need to write it :) | 23:52 |
| lifeless | jelmer: I'd like to see it too, but ETIME. | 23:52 |
| jelmer | lifeless, I was afraid that's what you were going to say :-) | 23:52 |
| lifeless | jelmer: did you have any idea why the compressbench thing worked for you? | 23:53 |
| lifeless | jelmer: also, could you paste me a comparison of knit<->git<->dulwich using that | 23:53 |
| jelmer | lifeless, do you remember the arguments? | 23:54 |
| lifeless | --delta git --delta dulwich --delta knit | 23:54 |
| lifeless | oh, and --limit if you have a really big repo, otherwise it will use all the inventories | 23:54 |
| jelmer | ok | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!