| lifeless | fullermd: there is one particular vicious bug, which abentley suggested a great fix for | 00:00 |
|---|---|---|
| lifeless | but noone has executed it | 00:00 |
| fullermd | I take exception to commands doing totally different things. Special cases are bad. | 00:00 |
| lifeless | fullermd: I agree with you | 00:00 |
| fullermd | Especially when every other VCS has an 'update' command that goes between a WT and its Branch (or whatever equivalent that VCS has) | 00:01 |
| lifeless | fullermd: well, git doesn't, hg doesn't do wt <-> branch (it does something different again), svn and cvs's updates are behaviourally identical to bzr's | 00:02 |
| lifeless | (modulo the 'check out new files' aspect. | 00:02 |
| fullermd | Well, git re-abuses 'checkout' for that. | 00:03 |
| fullermd | And hg's update DOES update the WT to something based on the branch. | 00:03 |
| fullermd | Anyway. I totally don't have the time or the energy for the whole co/bb discussion. | 00:04 |
| lifeless | it changes the working copy to a revision | 00:04 |
| lifeless | fullermd: ok | 00:04 |
| lifeless | fullermd: I want to get to the bottom of it some day | 00:04 |
| fullermd | sven_oostenbrink: Are you going to be around for a while yet? | 00:04 |
| lifeless | I think we should fix the polish bugs we have first | 00:04 |
| fullermd | Oh, totally. I wouldn't keep grumping about it if I didn't want to get it dealt with eventually :) | 00:05 |
| lifeless | :P | 00:05 |
| fullermd | I certainly agree that some of the behaviors (like that two-merge-update) are flat-out bugs, and need to be fixed irregardless of other issues. | 00:05 |
| === davidstrauss_ is now known as davidstrauss | ||
| fullermd | sven_oostenbrink: I have some discussions of 'mainline' I can put together and post up, but it's 18:00 and I reallyseriouslydesperately wanna go have lunch. So it'll be a while. | 00:07 |
| lifeless | mwhudson: so at this point you forward your confirmation mail to plans@tripit.com and magic happens | 00:07 |
| phoenixz | fullermd: another thing.. since this is a DVCS.. if I want to have a backup of my work, I only need to have a copy of the .bzr directory, right? | 00:08 |
| fullermd | phoenixz: Yeah. Though realize that every branch (or at least, every shared repo) is a 'backup' too. We commonly back up branches via 'push' ;) | 00:09 |
| fullermd | phoenixz: See above about mainline. | 00:09 |
| dash | phoenixz: to emphasize this fact, note that pushing to a remote branch does not create or modify the remote branch's working tree. :) | 00:10 |
| phoenixz | gottit, get some food, don't want you to starve to death, who else will help me out here? :) | 00:10 |
| fullermd | Somebody else, who won't get into an argument with lifeless in the middle of it? 8-} | 00:11 |
| phoenixz | dash: yeah, I was basically talking about branches with WT that would not contain changes.. | 00:11 |
| phoenixz | heheh | 00:11 |
| fullermd | phoenixz: BTW, you say that AboutUsingRepositories link as well, yse? | 00:17 |
| phoenixz | fullermd: yeah, saw it, will give it a read in a moment | 00:17 |
| Peng_ | jam: I might not have recompiled all of the extensions before the "merge" error. I'll see if I can reproduce it. | 01:36 |
| Peng_ | jam: Ehh, I'll follow up in an email. | 01:38 |
| Peng_ | jam: Short answer: I can't reproduce the errors. Looks like I did forget to recompile. | 01:44 |
| lifeless | james_w: around? | 01:47 |
| jfroy|work | jelmer: is there a way to push to a local (e.g. file) svn repository with bzr-svn? | 01:48 |
| jfroy|work | is seems there's no way to separate the branch name / path from the repository URL / path | 01:48 |
| wgrant | jfroy|work: WFM with file:// URLs. | 01:51 |
| jfroy|work | WFM? | 01:51 |
| wgrant | Works for me. | 01:51 |
| jfroy|work | mmm | 01:51 |
| wgrant | And it also seems to work with just a normal absolue path. | 01:51 |
| jfroy|work | well yeah, if you want to push to another bazaar branch | 01:52 |
| jfroy|work | I'm trying to push from bzr to a local svn repositoru | 01:52 |
| jfroy|work | *repository | 01:52 |
| wgrant | How does it complain when you try? It works fine for me. | 01:53 |
| jfroy|work | not a branch or directory already exists | 01:54 |
| jfroy|work | Ahh | 01:54 |
| wgrant | That's from 'bzr push /path/to/repo/path/to/subpath'? | 01:54 |
| jfroy|work | dpush fails, push works | 01:54 |
| jfroy|work | (I was trying to use dpush) | 01:54 |
| wgrant | Ahh. | 01:55 |
| jfroy|work | Ok, that's a new one | 01:55 |
| jfroy|work | bzr: ERROR: [Errno 24] Transaction cleanup failed | 01:55 |
| wgrant | New to me also. | 01:56 |
| mwhudson | lifeless: i wonder if tripit is going to understand the air nz itinerary in pdf i just mailed it... | 02:03 |
| lifeless | possibly :P | 02:05 |
| mwhudson | hm, it seems like it did, but now i can't find it online | 02:05 |
| mwhudson | ah, just took a while | 02:06 |
| lifeless | 'magic' | 02:06 |
| jfroy|work | so I just don't see how to use dpush | 02:06 |
| jfroy|work | (I really don't want the metadata) | 02:07 |
| lifeless | jfroy|work: file a bug :) | 02:07 |
| jfroy|work | it won't create the branch if it doesn't exists, and when it does, its error message stating I should pass --overwrite ends in failure because it doesn't have an overwrite option! | 02:07 |
| lifeless | mwhudson: indeed, it did better than for me; it thinks I stay in chch :P | 02:08 |
| lifeless | I guess I should tell them somehow | 02:08 |
| lifeless | which is odd vause their detailed view is right | 02:08 |
| mwhudson | it even coped with the hotel confirmation | 02:10 |
| mwhudson | lifeless: i think they might be using memcache or something a bit much | 02:10 |
| mwhudson | taking the "eventually consistent" to extremes | 02:10 |
| lifeless | mwhudson: we have longer lag than you saw, I think | 02:13 |
| jfroy|work | well, having more luck pushing to a svnserve-ed repository | 02:15 |
| igc | maxb: re storing git refs in bzr nicks, I'd like to explore the idea. Storing the value exactly probably isn't the best choice but having a deterministic mapping is a great idea | 02:23 |
| lifeless | igc: do you mean the object sha, or the human reflog name? | 02:27 |
| igc | lifeless: human name | 02:27 |
| Peng_ | Either something odd has happened, or lp:~jameinel/bzr/2.1-static-tuple-chk-map has really helped Loggerhead's memory usage. | 03:04 |
| * igc food | 03:07 | |
| * fullermd wouldn't rule out 'both', just on GP :p | 03:07 | |
| jfroy|work | so I don't understand fast-export :| | 03:08 |
| jfroy|work | no matter what bzr branch I export, it always seems to re-import it as trunk | 03:08 |
| jfroy|work | ahhh, 0b | 03:15 |
| jfroy|work | *-b | 03:15 |
| jfroy|work | magic | 03:15 |
| jfroy|work | do I need to re-export marks (whatever those are) if I have more than 2 branches to export and import? | 03:19 |
| jfroy|work | or do I need --export-marks only for the first export-import, and only need to use --import-marks for all subsequent export-imports? | 03:20 |
| mwhudson | spiv, lifeless: so i think the smart server doesn't handle unicode paths very well | 03:39 |
| lifeless | mwhudson: backtraces, details, please. | 03:40 |
| mwhudson | lifeless: run bzr serve --allow-write somewhere | 03:41 |
| mwhudson | bzr push bzr://localhost/b%C3%A9 | 03:41 |
| mwhudson | --> http://pastebin.ubuntu.com/299462/ | 03:42 |
| mwhudson | on the server side, Transport.__init__ is seeing a 'base' of filtered-41598608:///b\xc3\xa9/ | 03:46 |
| lifeless | yup thats wrong | 03:46 |
| mwhudson | sigh | 03:47 |
| mwhudson | i think sftp has different bugs like this :( | 03:47 |
| mwhudson | is there some way i can see what's going over the wire easily? | 03:49 |
| mwhudson | huh nosmart+bzr:// works finer | 03:51 |
| mwhudson | -r | 03:51 |
| lifeless | tcpdump | 03:58 |
| fullermd | phoenixz: http://bazaar-vcs.org/MatthewFuller/AboutMainline | 04:00 |
| mwhudson | the path is sent across the wire unescaped | 04:07 |
| mwhudson | http://pastebin.ubuntu.com/299476/ fixes things, maybe | 04:10 |
| Peng_ | This "pretend the screen is 65,536 columns wide" thing is causing problems. :\ | 04:10 |
| Peng_ | Including test failures. :D | 04:11 |
| spiv | mwhudson: hmm | 04:12 |
| Peng_ | (And yes I'll file bugs, once I verify that that's what's responsible.) | 04:12 |
| spiv | mwhudson: seems plausible I guess | 04:13 |
| lifeless | mwhudson: in fact u1 have rolled back to paste, spawning was too much fail :) | 04:13 |
| spiv | mwhudson: I wonder about paths sent in responses, but one problem at a time... | 04:13 |
| Peng_ | "u1"? | 04:13 |
| lifeless | Peng_: ubuntuone | 04:13 |
| mwhudson | lifeless: ugh | 04:16 |
| mwhudson | lifeless: oh well, my business with other things saved me some pain there i guess | 04:16 |
| mwhudson | spiv: uh yes i guess so | 04:18 |
| Peng_ | How should environment variables be handled in tests? If you change one, will it be automagically fixed when the test ends? | 04:18 |
| mwhudson | spiv: which smart verbs respond with paths? | 04:18 |
| mwhudson | Peng_: there is certainly some support in testcase for that | 04:19 |
| lifeless | Peng_: many common ones are automatically saved and restored | 04:19 |
| Peng_ | "common ones"? | 04:19 |
| lifeless | plugins path, email, HOME, editor etc | 04:20 |
| lifeless | see bzrlib.tests | 04:20 |
| Peng_ | Ah. | 04:21 |
| Peng_ | They're fixed after every test? So it's okay to mess with them? | 04:23 |
| lifeless | the set that are isolated, yes | 04:24 |
| lifeless | those that aren't, you should call the isolation helper on first | 04:24 |
| arjenAU | ahoy my beloved bzr magicians | 04:25 |
| lifeless | ahrr | 04:25 |
| arjenAU | i come to you in search of enlightenment. | 04:25 |
| arjenAU | lifeless: stay put you, i'm a happy user! | 04:25 |
| lifeless | I was doing pirate | 04:25 |
| arjenAU | I need something akin to a hardlink in a branch | 04:25 |
| * fullermd is a couple doves short of a sixpack. | 04:25 | |
| lifeless | in the ahoy theme | 04:25 |
| arjenAU | oh righty | 04:25 |
| arjenAU | lifeless: ideas? | 04:26 |
| arjenAU | so I need a file in 2 or 3 directories, and keep 'em in sync. no risk of divergence. a straight link would do it, if bzr can grok that. | 04:27 |
| lifeless | arjenAU: bzr can version symlinks | 04:27 |
| arjenAU | ok so I'd have a main and secondary... that would do. just not hardlinks? and I presume the symlinks break on windows or did you use the magic API to use it on NTFS? | 04:28 |
| arjenAU | i don't need win, just curious ;-) NTFS supports symlinks but win doesn't use 'em | 04:28 |
| lifeless | we degrade on windows | 04:29 |
| lifeless | there is a plugin | 04:29 |
| lifeless | to do something more than we do | 04:29 |
| arjenAU | lifeless: no worries. ok so symlinks. ok out of the box or do I need to set anything to make this jive? | 04:29 |
| lifeless | ln -s foo bar | 04:29 |
| lifeless | bzr add | 04:29 |
| arjenAU | sounds sane as usual. ok | 04:29 |
| arjenAU | then, can I get conflicts on a bzr pull if I didn't have any local changes that weren't pushed? | 04:30 |
| lifeless | sorry, rephrase that wont | 04:30 |
| lifeless | s/wont/one/ | 04:30 |
| arjenAU | euh? | 04:30 |
| lifeless | I don't understand the question :) | 04:30 |
| arjenAU | I do a bzr pull and I get conflicts, even though I have no local divergence afaik | 04:30 |
| lifeless | you may have local changes | 04:31 |
| lifeless | such as files that are ignored in a subdirectory | 04:31 |
| arjenAU | not on those files. | 04:31 |
| lifeless | or uncommitted edits to a file | 04:31 |
| arjenAU | i've seen this a few times ove rlast week or so. using 2.0 | 04:31 |
| arjenAU | well jaunty ppa | 04:31 |
| arjenAU | it's honestly files I have not touched. | 04:32 |
| lifeless | could you, for a while, do 'bzr st; bzr pull' | 04:32 |
| lifeless | and when it happens file a bug with the output of those two commands - the order matters ;) | 04:32 |
| spiv | mwhudson: lots of them | 04:32 |
| arjenAU | lifeless: rigthy. can I nicely back out of the current state totry that again. revert? | 04:32 |
| jam | lifeless: I don't remember it happening for files, but if you delete a directory, then you can get a conflict if there are temp files lying around | 04:32 |
| jam | Peng_: I would like to think 'static-tuple-chk-map' helps mem, but I wouldn't have expected it to effect loggerhead | 04:33 |
| lifeless | jam: yes, thats why I mentoned ignored iles in subdirs | 04:33 |
| Peng_ | jam: Hi. :) | 04:33 |
| lifeless | arjenAU: no, because we don't have the exact state any more | 04:33 |
| jam | lifeless: I'm currently trying to get meliae to perform 'compute_referrers' on a 500MB dump file w/ 5.6M objects. | 04:34 |
| spiv | mwhudson: list_dir obviously, but also I think various opening verbs can e.g. BzrDir.find_repositoryV3 and Branch.get_config_file and probably several others. | 04:34 |
| jam | The problem is that a dict holding 5.6M entries is 200MB by itself... | 04:34 |
| Peng_ | jam: Well, Loggerhead does read data that comes through bzrlib.chk_map. | 04:34 |
| jam | Peng_: for iter_changes? | 04:35 |
| arjenAU | lifeless: ehm. so to get rid of the mess, I did bzr revert then bzr clean-treeto be sure I didn't have build leftovers. then bzr pull says no rvisions to pull.... so it's just the local checkout that's the issue now, right? what command? or did I go foul somewhere | 04:35 |
| Peng_ | jam: No clue. I know it hits iter_ancestry, but I forget how. | 04:35 |
| lifeless | arjenAU: well, thats the thing, we don't have the state that caused the conflicts | 04:36 |
| lifeless | arjenAU: so we need to wait for it to happen again | 04:36 |
| lifeless | arjenAU: thus my asking you to do 'bzr st; bzr pull' from here on in, to capture more detail when it happens again. | 04:36 |
| mwhudson | spiv: list_dir agrees on the encoding with that via a local transport fwiw | 04:36 |
| jam | arjenAU: so if you get conflicts, 'bzr revert' should restore you to the pristine state, however, as lifeless says, determining what got you there in the first place would be useful | 04:37 |
| arjenAU | yes I get that, but I don't understand the situation I now have in my tree. | 04:37 |
| mwhudson | >>> get_transport('bzr://localhost').list_dir('.') == get_transport('/home/mwh/tmp').list_dir('.') | 04:37 |
| mwhudson | True | 04:37 |
| spiv | That's good. | 04:38 |
| Peng_ | jam: Loggerhead caches a copy of the revision graph. . . | 04:38 |
| jam | mwhudson: yeah, I would use list_dir() as a guideline for how paths should be encoded | 04:38 |
| jam | Peng_: revision graph comes from the indices | 04:38 |
| jam | I thought it also cached the per-revision deltas | 04:39 |
| mwhudson | yeah, it does | 04:39 |
| jam | and that could certainly come from chk_map | 04:39 |
| mwhudson | though not in ram very much i think | 04:39 |
| arjenAU | jam: if you need graph magic, look at http://openquery.com/blog latest entry, you may find useful. | 04:39 |
| spiv | mwhudson: oh, and of course the various error responses that contain paths | 04:39 |
| spiv | mwhudson: e.g FileExists | 04:40 |
| Peng_ | jam: FYI, I just ran "bzr selftest" on bzr.dev + 2.1-static-tuple-chk-map + statictuple-pickling, and there were no failures (related to ST, anyway) | 04:41 |
| mwhudson | argh | 04:42 |
| mwhudson | now get_transport('bzr://localhost').mkdir('b%C3%A9bbb') creates a directory with the escaped path :( | 04:43 |
| spiv | mwhudson: :( | 04:43 |
| spiv | mwhudson: so clients today are sometimes sending utf-8 bytes and sometimes sending urlutils.escape'd? | 04:46 |
| mwhudson | spiv: it seems that way | 04:47 |
| mwhudson | spiv: at a guess bzrlib.remote and bzrlib.transport.remote are different | 04:47 |
| spiv | mwhudson: is it varying by verb only? | 04:47 |
| mwhudson | spiv: not sure | 04:48 |
| mwhudson | spiv: actually | 04:48 |
| spiv | If it's just a difference between VFS verbs and not, that's not too bad | 04:48 |
| mwhudson | spiv: what do you mean by that question? :) | 04:48 |
| spiv | I mean, for every verb X, do clients consistently send paths a particular way? | 04:49 |
| mwhudson | spiv: i don't think there are cases where the same verb is called with varying levels of escaped-ness | 04:49 |
| igc | lifeless, jam: any hints on where I should look to solve bug 441125? | 04:49 |
| spiv | Right | 04:49 |
| ubottu | Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [High,In progress] https://launchpad.net/bugs/441125 | 04:49 |
| mwhudson | spiv: right, yes, afaik | 04:49 |
| spiv | That's what I'd expect (and hope) | 04:49 |
| lifeless | igc: isn't it a dupe? | 04:49 |
| spiv | If so, that's not insurmountable. | 04:49 |
| igc | lifeless: not sure. It's well beyond my knowledge area | 04:50 |
| spiv | Especially if the split is exactly VfsRequest/everything-else | 04:50 |
| spiv | mwhudson: so bzrlib.remote calls something that seems to intentionally unquote the url before transmission | 04:51 |
| mwhudson | spiv: if you say so, i've become a bit lost among the various objects & methods | 04:52 |
| jam | lifeless: so if I understand the exception, it is triggering because an inventory is referring to a file key (file_id, revision) which is *not* present in the repository | 04:52 |
| jam | sorry igc^^ | 04:52 |
| jam | which is certainly bad-mojo | 04:53 |
| jam | is this a stacked branch? | 04:53 |
| igc | jam: yes | 04:53 |
| lifeless | spiv was fixing a bug like this yesterday | 04:53 |
| lifeless | or so | 04:53 |
| jam | and does reconcile fail on the base? | 04:53 |
| igc | jam: reconcile on the trunk works ok | 04:53 |
| spiv | mwhudson: specifically RemoteBzrDir._path_for_remote_call invokes _SmartClient.remote_path_from_transport invokes the medium's remote_path_from_transport | 04:53 |
| igc | jam: it's only on the stacked branch it fails | 04:53 |
| spiv | mwhudson: both implementions of that make a urlutil.relative_url and urlutils.unquote it. | 04:54 |
| igc | jam: branching from there gives a branch on which reconcile works | 04:54 |
| jam | igc: so one possibility is to probe through all of the inventories to find one that references this text key | 04:54 |
| igc | jam: can comparing the log -v -p on the orginal branch and the created branch gives the same results | 04:54 |
| jam | it is certainly possible that this inventory is 'unreferenced' | 04:54 |
| spiv | mwhudson: where bzrlib.transport.remote uses RemoteTransport._remote_path which appears to rely on whatever Transport._combine_paths does | 04:55 |
| jam | (or, not in the ancestry) | 04:55 |
| mwhudson | spiv: ah right | 04:55 |
| jam | _text_refs is built up by walking *all* chk pages, IIRC | 04:55 |
| jam | not just chaining from revisions => inventories => chk_pages | 04:55 |
| mwhudson | spiv: so a cheap hack would be to have VfsRequest override translate_client_path to unescape again? | 04:56 |
| jam | hold on... maybe not. Maybe only ones that are referenced via an inventory | 04:56 |
| spiv | lifeless, jam, igc: The bug lifeless is thinking of that I fixed is bug 437626, I think | 04:56 |
| ubottu | Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [High,Fix committed] https://launchpad.net/bugs/437626 | 04:56 |
| jam | it looks like unreferenced ones are just streamed out directly, without being parsed. | 04:56 |
| mwhudson | spiv: https://code.edge.launchpad.net/~mwhudson/bzr/escape-smart-server-requested-paths fwiw | 04:57 |
| spiv | lifeless, jam, igc: which didn't affect 2a repos, if that helps | 04:57 |
| igc | spiv: thanks | 04:57 |
| jam | however, that doesn't mean we have the *revision* for that inventory | 04:57 |
| igc | (it does) | 04:57 |
| lifeless | jam: unrefed ones shouldn't be copied though | 04:57 |
| lifeless | jam: except for the adjacent ones, and those we don't want the texts for | 04:57 |
| spiv | mwhudson: I think so | 04:58 |
| igc | jam, lifeless: so does that imply reconcile is looking at extra data it doesn't need to? | 04:58 |
| spiv | mwhudson: or not apply your escaping | 04:59 |
| spiv | mwhudson: whatever works is fine by me, though :) | 04:59 |
| lifeless | igc: possibly yes | 04:59 |
| mwhudson | spiv: is it sane to have vfs requests have different rules than the others? | 04:59 |
| spiv | mwhudson: we'll need tests, obviously, and I should add some text about this to network-protocol.txt | 04:59 |
| jam | igc: it is possible to have inventories in the repository that aren't referenced by the branch. it is further possible for those to be borked. | 05:00 |
| spiv | mwhudson: well, they already do AIUI? | 05:00 |
| jam | hence why I suggested you walk all inventories and find out which one thinks it knows something about the given file_key | 05:00 |
| mwhudson | spiv: i guess | 05:00 |
| mwhudson | fixing it would require defining a whole new tranche of verbs | 05:00 |
| spiv | mwhudson: the long term plan is to remove the vfs requests anyway, so if there's cruft that's restricted to just them I'm fairly comfortable with that | 05:01 |
| jam | for inv in b.repository.iter_inventories([k[0] for k in b.repository.inventories.keys()]): | 05:01 |
| spiv | mwhudson: and as far as cruft goes this is pretty minor, happily. | 05:01 |
| jam | if file_key in inv: | 05:01 |
| mwhudson | spiv: true enough | 05:01 |
| jam | print inv.revision_id | 05:01 |
| mwhudson | spiv: where are the vfs verbs tested? | 05:03 |
| mwhudson | just in the generic transport tests applied to RemoteTransport? | 05:05 |
| spiv | mwhudson: mainly those, yeah | 05:05 |
| spiv | mwhudson: there's also a little bit SmartServerRequestHandlerTests in test_smart_transport | 05:05 |
| spiv | mwhudson: most of the newer verbs are more rigorously tested in test_smart | 05:06 |
| mwhudson | spiv: i guess an appropriate test for this is to have a RemoteTransport onto a directory, mkdir('%C3%A9'), and then check list_dir via a LocalTransport matches? | 05:10 |
| mwhudson | spiv: can i get you to write that? :-) | 05:11 |
| igc | jam: thanks for the code snippet. That saved me ages I'm sure ... | 05:13 |
| igc | jam: I get 202 matches on that file-id and the rev-id is one of them | 05:14 |
| igc | i.e. rev-id failing in the KeyError exception | 05:14 |
| igc | jam: make that 280 matches sorry | 05:14 |
| spiv | mwhudson: I suppose so, although it's not my ideal way to spend a Friday afternoon ;) | 05:14 |
| mwhudson | argh | 05:15 |
| * mwhudson is all confused again :( | 05:15 | |
| spiv | mwhudson: but yes, that sounds like a good test to have | 05:15 |
| spiv | mwhudson: oh, except I'd back it onto a MemoryTransport :) | 05:15 |
| mwhudson | spiv: https://bugs.edge.launchpad.net/bzr/+bug/458762 | 05:47 |
| ubottu | Launchpad bug 458762 in bzr "smart client inconsistent about escaping of paths to the surprise of the smart server" [Undecided,New] | 05:47 |
| mwhudson | spiv: can i assign that to you? | 05:47 |
| spiv | mwhudson: no | 05:48 |
| spiv | mwhudson: because I just did :) | 05:48 |
| mwhudson | spiv: ok :) | 05:48 |
| spiv | mwhudson: thankks | 05:48 |
| mwhudson | spiv: np | 05:49 |
| mwhudson | spiv: i'm glad the problem turned out to be fairly simple in the end | 05:49 |
| === AfC1 is now known as AfC | ||
| jkakar | lifeless: I've written a command to upgrade Bazaar branches on Launchpad. I'm not sure it's working. Do the formats here make sense: http://pastebin.ubuntu.com/299569/ | 07:01 |
| lifeless | jkakar: lp has a bug where it doesn't update the reported format | 07:05 |
| lifeless | jkakar: bzr info nosmart+<url> | 07:05 |
| jkakar | lifeless: Ah ha, I was wondering about that. | 07:05 |
| jkakar | lifeless: Woot: http://pastebin.ubuntu.com/299574/ | 07:07 |
| lifeless | its been upgraded :) | 07:07 |
| jkakar | It's probably a good time to make the first release of AutoLP. | 07:08 |
| lifeless | autolp ? | 07:08 |
| jkakar | I want a place to collect Launchpad commands. I already have several scattered about. | 07:08 |
| lifeless | lptools | 07:08 |
| lifeless | https://code.edge.launchpad.net/lptools | 07:08 |
| lifeless | and there is another one as well that the lp folk made | 07:08 |
| lifeless | (that meaning rockstar/jml/abentley I think, though I'm hazy) | 07:09 |
| jkakar | I didn't know about lptools, will check it out, thanks. | 07:09 |
| lifeless | it has a review-notifier which is nifty | 07:09 |
| lifeless | on my TODO to package it | 07:09 |
| wgrant | Might want to add lptools to the lpx project group. | 07:09 |
| lifeless | lpx? | 07:09 |
| lifeless | surely launchpad ? | 07:09 |
| wgrant | A new officially-sanctioned project group for launchpadlib-using applications. | 07:10 |
| jkakar | Launchpad Extensions, similar to the tx project group for Twisted. | 07:10 |
| lifeless | mmm | 07:10 |
| lifeless | seems totally weird to me to not use the launchpad group | 07:10 |
| wgrant | They are not part of LP. | 07:10 |
| lifeless | so? | 07:11 |
| wgrant | To they should not be part of LP. | 07:11 |
| wgrant | s/To/So/ | 07:11 |
| lifeless | you're repeatin yourself but not making a case | 07:11 |
| wgrant | They are not part of LP in the real world, so why should they be part of LP on LP? | 07:11 |
| lifeless | the launchpad project group isn't just launchpad.net | 07:11 |
| jkakar | I like having a way to separate "Launchpad the moving parts of the service" from "The set of tools that work with Launchpad". | 07:12 |
| lifeless | it needs to be shrunk if thats what its meant to be an exact match for | 07:12 |
| lifeless | jkakar: I can see that | 07:12 |
| lifeless | project tags FTW | 07:12 |
| jkakar | Yeah. :) | 07:12 |
| wgrant | Right. lpx is brand new, and things haven't been sorted out yet. | 07:12 |
| * lifeless sighs over data models | 07:13 | |
| lifeless | so limiting | 07:13 |
| igc | lifeless: the reconcile problem seems to come down to parent_map(text_refs) not finding all parents | 07:13 |
| igc | lifeless: so maybe we aren't collecting things correctly for a stacked branch? | 07:14 |
| lifeless | igc: reconcile runs in unstacked mode | 07:14 |
| lifeless | igc: because it has to enforce 'this repo is internally consistent' | 07:14 |
| igc | groupcompress_repo.py, line 1289 | 07:14 |
| igc | text_refs has 5024 items | 07:15 |
| lifeless | igc: do you perhaps mean 'reconcile is not fully up to date with the setup of stacked repositories' | 07:15 |
| igc | parent_map returns a dict with 4875 keys | 07:15 |
| igc | I may mean that, still fumbling my way through | 07:16 |
| igc | lifeless:^^^ | 07:16 |
| lifeless | :) | 07:16 |
| lifeless | I'm done for the day btw | 07:16 |
| lifeless | should have been, oh, 3 hours back. But I'm bad at 8 hour days | 07:16 |
| igc | lifeless: sorry. not great timing I know | 07:16 |
| igc | lifeless: I'll update the bug report and look more on Monday | 07:17 |
| lifeless | kk | 07:17 |
| lifeless | win 32 | 07:18 |
| vila | hi all | 07:21 |
| vila | lifeless: win 32... 2000 ? XP ? Vista ? :-P | 07:21 |
| igc | hi vila | 07:25 |
| lifeless | wgrant: its a shame that bzr, and various things with lp support won't ever be able to be in lpx :P | 07:30 |
| bialix | privet | 07:35 |
| wgrant | lifeless: This is why we need project tags. | 07:35 |
| bialix | oh! my favorite subject: project tags | 07:35 |
| * bialix looks at irclogs | 07:36 | |
| lifeless | wgrant: I know :) | 07:36 |
| lifeless | hi vila | 07:36 |
| igc | lifeless: I'm seeing *much* better memory usage having dropped the cache size down to 1 by default, along with the latest bzr trunk with jam's improvements | 07:53 |
| igc | lifeless: you may want to retry a netbeans import when you get a chance | 07:54 |
| lifeless | igc: I'll teach you the cache mantra eventually ;) | 07:54 |
| igc | it helped at the time :-) | 07:54 |
| igc | but I'm really pleased it's mostly not needed now | 07:55 |
| lifeless | hows the performance? | 07:55 |
| igc | better! | 07:55 |
| lifeless | good | 07:55 |
| lifeless | gc costs a lot :) | 07:55 |
| igc | well, better or medium to large projects | 07:55 |
| igc | on | 07:56 |
| igc | it's slower on smaller projects but not by a big amount | 07:56 |
| spiv | igc: nice | 07:56 |
| igc | spiv: well, turning off a cache is simple - jam and you guys did the hard yards making the core fast enough that it wasn't helpful! | 07:57 |
| igc | spiv: but thanks :-) | 07:57 |
| * igc dinner | 08:18 | |
| lifeless | vila: forward your trip booking mail to plans@tripit.com, should create an itinery :) | 08:21 |
| vila | lifeless: yup, I'm trying to sort out the email used first, but thanks for the t[r]ip :) | 08:21 |
| vila | lifeless: next time, treat me as spiv but with a '+' instead of '-' ! | 08:22 |
| loxs_wrk | what do I need to do in order to revert some file to the state from the previous revision | 08:25 |
| lifeless | vila: I wasn't sure if they were magic oryou had to configure it | 08:26 |
| lifeless | loxs_wrk: bzr revert -r -2 FILE | 08:27 |
| vila | lifeless: '+' is the "standard" magic char, spiv cheats :-P | 08:27 |
| vila | bah, I can't find the merge accounts anymore, will just delete the othr | 08:28 |
| vila | bug 353370 upsets babune a lot, do you I need to submit a proposal to revert revnos 4766 and 4764 or can I just go ahead ? | 08:54 |
| ubottu | Launchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,In progress] https://launchpad.net/bugs/353370 | 08:54 |
| lifeless | james_w: you has bugs | 11:13 |
| james_w | lifeless: you has responses to bugs | 11:13 |
| lifeless | james_w: also a merge request on -builder; would love to have a todo-to-merge for it for Monday | 11:13 |
| lifeless | james_w: thanks | 11:13 |
| lifeless | james_w: did you only just comment? I don't see bugmail.. | 11:15 |
| james_w | about an hour ago | 11:15 |
| james_w | for "needs -sa" I said "eh?" | 11:16 |
| james_w | bzr-builder currently builds native packages to sidestep tarball issues | 11:16 |
| james_w | so you shouldn't have an issue | 11:16 |
| james_w | for "invalid email address" I said that I couldn't see how it happened given the code | 11:17 |
| james_w | though I didn't look that closely | 11:17 |
| james_w | knowing what $DEBEMAIL $DEBFULLNAME $MAIL $NAME $EMAIL were in your environment | 11:18 |
| lifeless | dch -a gets something more 'sane' (though still not great) | 11:19 |
| james_w | this uses a port of dch's algorithm, so it should give the same behaviour | 11:19 |
| james_w | I can believe that we made a mistake in porting though | 11:19 |
| lifeless | I saw, it doesn't. | 11:19 |
| lifeless | $ echo a $DEBEMAIL b $DEBFULLNAME c $MAIL d $NAME e $EMAIL | 11:19 |
| lifeless | a b c /var/mail/bobthebuilder d e | 11:19 |
| james_w | $MAIL looks wrong to me | 11:19 |
| james_w | or not | 11:20 |
| james_w | I wonder where Javier got MAIL from, dch doesn't seem to use it | 11:21 |
| lifeless | looks fine to me | 11:21 |
| lifeless | its the maildir for the user | 11:21 |
| lifeless | I can't imagine it ever being useful for email address detection | 11:21 |
| lifeless | bzr has a pretty complete heuristic itself, built in | 11:22 |
| james_w | ok | 11:22 |
| james_w | yeah, I wanted the same as dch though | 11:22 |
| james_w | I thought that would be less surprising | 11:22 |
| lifeless | so the mail thing was a distraction | 11:22 |
| james_w | using bzr stuff as a fallback before the "guess based on socket.fqdn" though | 11:22 |
| lifeless | took me a bit of time to realise that it wasn't lp api's giving me grief :) | 11:23 |
| lifeless | the merge proposal is more interesting to me than the bug now [as I has workaround] | 11:23 |
| lifeless | its lightly tested as there doesn't seem to be any test support for lp apis | 11:25 |
| lifeless | [and cody gave me a chunk of the code in one hit] | 11:25 |
| james_w | yeah, I'm reviewing that now | 11:25 |
| james_w | lifeless: if you could respond to the other bug I would appreciate it | 11:27 |
| * james_w doesn't like incomplete bugs | 11:27 | |
| lifeless | james_w: I thought I replied to both | 11:28 |
| james_w | ok | 11:29 |
| james_w | hanks | 11:29 |
| lifeless | yeah, I did | 11:30 |
| lifeless | just bugmail slowness | 11:30 |
| lifeless | really, smtp==www, should be instant :) | 11:30 |
| james_w | lifeless: review done | 11:48 |
| james_w | thanks for working on this | 11:49 |
| bialix | bzr guru I have a question about bzrdir.sprout | 12:02 |
| bialix | Bug 458914 | 12:03 |
| ubottu | Launchpad bug 458914 in bzr-scmproj "pget clone all revisions from shared repository instead of revisions belong to .scmproj branch" [High,Confirmed] https://launchpad.net/bugs/458914 | 12:03 |
| bialix | I have following code in scmproj to clone control branch | 12:03 |
| bialix | http://pastebin.com/d5939252d | 12:04 |
| bialix | this code using sprout | 12:04 |
| bialix | as result it does not filter out unrelated revisions when cloning branch | 12:04 |
| bialix | but get entire shared repo | 12:05 |
| bialix | what I'm doing wrong? | 12:05 |
| vila | bialix: why don't you use branch.fetch() instead ? And why does your comment talks about creating a working tree for force_new_repo ? | 12:10 |
| bialix | I dunno, that code was written by amanica | 12:10 |
| bialix | I don't understand how sprout works | 12:10 |
| vila | :-/ | 12:10 |
| bialix | that code invoked this way: http://pastebin.com/d41766d3d | 12:11 |
| bialix | wait | 12:12 |
| bialix | are you asking about comment after force_new_repo=True ? | 12:12 |
| bialix | vila: ^ | 12:12 |
| vila | yes | 12:12 |
| bialix | the idea was is to create standalone branch always, regardless of presence of shared repo | 12:13 |
| vila | bialix: especially when sprout has a _create_tree_if_local parameter... | 12:13 |
| vila | ha | 12:13 |
| bialix | _create_tree has leading underscore, therefore it's private API | 12:13 |
| bialix | last time you was very hard that gary using private api in qbzr | 12:14 |
| vila | meh, no underscore, sorry typo | 12:14 |
| bialix | that code was written last winter, perhaps bzrlib evolved since then | 12:14 |
| vila | rhaa, I wasn't hard at all ! You misunderstood my intent, but nm | 12:15 |
| vila | bialix: you may want to use the revision_id parameter too | 12:16 |
| vila | if revision_id is not None, then the clone operation may tune | 12:16 |
| vila | itself to download less data. | 12:16 |
| vila | bialix: your caller certainly can get that from br_from.last_revision_info | 12:18 |
| bialix | vila: hmmm | 12:22 |
| bialix | strange | 12:22 |
| bialix | vila: so I need to change my clone fuinction? | 12:25 |
| vila | I'd say so... | 12:26 |
| bialix | :-/ | 12:27 |
| bialix | so I need to make function as def _clone_to_local_url(br_from, revisions_id, to_url, accelerator_tree=None): | 12:28 |
| bialix | vila: ^, right? | 12:28 |
| bialix | and pass revision_id to sprout? | 12:29 |
| vila | revision_id, no 's' , but yes, I'd try that | 12:29 |
| === mrevell is now known as mrevell-lunch | ||
| vila | bialix: do you have any evidence that this bug is recent or was it always there but unnoticed ? | 12:29 |
| bialix | my coworker just today discovered this | 12:31 |
| bialix | I think it was there always | 12:31 |
| bialix | but he has non-standard scmproj project clone | 12:32 |
| bialix | .scmproj should be standalone tree, we forcing this | 12:32 |
| bialix | but he made by hands this branch using shared repo | 12:32 |
| bialix | so it's not very critical but I'd like to fix it | 12:32 |
| * bialix trying what vila suggested | 12:34 | |
| vila | Peng: ping ! | 12:34 |
| bialix | Ping: peng | 12:34 |
| vila | Peng: just noticed bug #458743 and bug #458741 | 12:35 |
| ubottu | Launchpad bug 458743 in bzr "terminal_width fix causes progress bar hideousness when piped to "less"" [Undecided,New] https://launchpad.net/bugs/458743 | 12:35 |
| ubottu | Launchpad bug 458741 in bzr "terminal_width fix causes test failures with subunit" [Undecided,New] https://launchpad.net/bugs/458741 | 12:35 |
| vila | Peng: I've been bitten by the problem in another way and I just proposed lp:~vila/bzr/353370-notty-no-term-width | 12:36 |
| vila | Peng: your feedback will be highly welcome | 12:36 |
| vila | Peng: oh, and more info at bug #353370 | 12:36 |
| ubottu | Launchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,Fix committed] https://launchpad.net/bugs/353370 | 12:36 |
| bialix | vila: branch.py suggests that I can obtain rev_id tip by br_from.last_revision() call. ok? | 12:38 |
| vila | bialix: yup | 12:38 |
| bialix | cool | 12:39 |
| === weigon__ is now known as weigon | ||
| bialix | vila: many many thanks | 12:42 |
| bialix | merci | 12:42 |
| bialix | it working | 12:42 |
| vila | bialix: \o/ | 12:43 |
| bialix | all hail vila! | 12:43 |
| vila | :-D | 12:43 |
| * bialix mutters: that's new ajax lp made me crazy | 12:46 | |
| Peng_ | vila: AIUI (skimming things) your patch drops the no-TTY width from 65,536 to 256. My terminal is ~130 columns wide, so it should still get spammed, just a lot less. | 12:48 |
| Peng_ | vila: Is that correct? | 12:48 |
| vila | Peng: not only, it changes the way is obtained in more cases | 12:48 |
| vila | Peng: not only, it changes the way the width is obtained in more cases | 12:48 |
| vila | Peng: can you try it ? | 12:49 |
| vila | err, which Peng are you ? Peng or Peng_ ? :) | 12:49 |
| Peng_ | Oh look, I have $COLUMNS. 183? Didn't remember it was that high. | 12:50 |
| Peng_ | vila: Both. | 12:50 |
| Peng | vila: ...And neither! | 12:50 |
| vila | lol | 12:50 |
| vila | Right, so if you set COLUMNS, it's obeyed. Period. | 12:51 |
| Peng_ | OK, both of my computers have $COLUMNS. If it works, I don't really care about the details. :P | 12:51 |
| Peng_ | vila: I'll grab a copy of your branch. | 12:52 |
| vila | ok, I'll grab some food then :-) | 12:52 |
| * SamB_XP still wishes bzr paid attention to SIGWINCH | 12:52 | |
| vila | SamB_XP: patches welcome ! | 12:54 |
| SamB_XP | heck, I'm not even sure I made sure there was a bug about it! | 12:54 |
| vila | SamB_XP: see.... :-D | 12:55 |
| bialix | vila: thanks again, you my hero | 12:56 |
| Peng_ | That brings it to 4 branches I have merged to my bzr.dev. :D | 12:57 |
| Peng_ | vila: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one. | 13:00 |
| Peng_ | vila: when piped to less, anyway | 13:02 |
| Peng_ | vila: This is an improvement, obviously, but it's still worse than the old code. | 13:02 |
| vila | Peng: with or without COLUMN being set ? | 13:04 |
| vila | COLUMNS | 13:04 |
| Peng_ | vila: with | 13:06 |
| vila | Peng: and is the value coherent with your terminal ? | 13:06 |
| vila | i.e. <= | 13:06 |
| Peng_ | vila: Yes. | 13:09 |
| vila | Peng: you said earlier that COLUMNS was set to 183 and your terminal ~130, right ? | 13:10 |
| vila | anyway, try to either *not* set COLUMNS or set it to a value that is *less* than your terminal width | 13:11 |
| vila | Peng: regarding #458741, can you tell me how to reproduce that ? | 13:12 |
| Peng_ | vila: I just sent an email. All I did was "bzr selftest --parallel subprocess". | 13:13 |
| Peng_ | vila: Well, to be exact I did "bzr selftest --parallel subprocess pending". | 13:14 |
| * Peng_ runs off to watch TV. I'll check in at ad breaks, though. | 13:14 | |
| vila | ok, I can reproduce now, that's fixed with my patch | 13:15 |
| Peng_ | Ohh, why is there always an ad break right when I get up? | 13:15 |
| vila | Peng: at your next break, can you precisely tell me what width your terminal is, what COLUMNS value you use and if you still experience a problem | 13:15 |
| Peng_ | vila: 183, 183, and which problem? The selftest one? I'll check. | 13:15 |
| vila | the selftest one is fixed, just checkd it | 13:16 |
| Peng_ | vila: Yeah, I can confirm it. | 13:16 |
| Peng_ | vila: Which problem do you want me to check? | 13:17 |
| vila | You said: My terminal doesn't get flooded, but each time the progress bar updates, it prints a new line instead of overwriting the old one. | 13:17 |
| vila | I can't reproduce that | 13:18 |
| Peng_ | vila: Oh. ...Show's back. | 13:18 |
| Peng_ | vila: Anyway, that's with latest-everything, including your branch. And 3 others, but they shouldn't break this. | 13:18 |
| vila | ghaaa, I want a recipe to reproduce !!! :D | 13:19 |
| vila | ha, got it, if COLUMNS >> terminal_width I can see that, but if I use COLUMNS==terminal_width it's not the case, please double check | 13:19 |
| vila | and if COLUMNS >> terminal_width, well, it's kind of expected, if the terminal issue a linefeed, there is no way bzr can uses carriage returns to erase the current line (since it has become the previous line...) | 13:21 |
| === mrevell-lunch is now known as mrevell | ||
| vila | hmm, so, to be pedantically precise, the bug occurs if you set COLUMNS=terminal_width+2, so there probably is a off-by-one error somewhere | 13:23 |
| vila | Peng: but it also very probably means COLUMNS is not set the way you think it is :) | 13:23 |
| Peng_ | Hmm. | 13:29 |
| Peng_ | vila: $COLUMNS is right. | 13:30 |
| Peng_ | vila: Also, like I said, it only happens when I pipe to less. | 13:30 |
| Peng_ | vila: ....Now I can't reproduce it. | 13:30 |
| vila | Peng: haaaaa, I prefer that :-) THanks ! | 13:31 |
| Peng_ | vila: Sorry, I was wrong. I can reproduce it. | 13:31 |
| Peng_ | vila: It works fine if I do "COLUMNS=183 bzr pull -v | less -F", but fails if I just do "bzr pull -v | less -F". Even though $COLUMNS is 183 anyway. | 13:32 |
| vila | >-/ | 13:32 |
| Peng_ | Sorry. :P | 13:32 |
| vila | env | grep COLUMNS | 13:34 |
| vila | vila:~/src/bzr/releases/2.0 :( $ echo $COLUMNS | 13:34 |
| vila | 80 | 13:34 |
| vila | meh.... | 13:34 |
| vila | Peng: Can you try COLUMNS=182 | 13:35 |
| Peng_ | vila: "export COLUMNS=182; bzr pull -v | less -F" works. | 13:35 |
| vila | Peng: amazing isn't it ? | 13:35 |
| vila | so it's *another* off-by-one error somewhere else | 13:36 |
| Peng_ | vila: Bu I told you, 183 works. Sometimes. | 13:36 |
| Peng_ | But* | 13:36 |
| Peng_ | vila: "export COLUMNS=183; bzr pull -v | less -F" works too. Augh! | 13:37 |
| Peng_ | vila: Ah-ha! "echo $COLUMNS" works, but "env" doesn't list COLUMNS. | 13:39 |
| vila | seems related to 'shopt -s checkwinsize' in my .bashrc | 13:39 |
| Peng_ | vila: $TERMCAP does include the columns, though. | 13:39 |
| Peng_ | Although I only have $TERMCAP inside of screen, but that's mostly where I run bzr anyway, so it's not a big deal. | 13:40 |
| vila | Peng: I'm pretty sure we are chasing a different bug here... | 13:43 |
| Peng_ | vila: I dunno. What are we talking about? | 13:45 |
| vila | off-by-one errors bewtween terminal width and COLUMNS | 13:46 |
| vila | before my patch COLUMNS wasn't obeyed, so you didn't see these bugs | 13:46 |
| Peng_ | So, um, hmm. Since it turns out I don't actually have $COLUMNS ("echo" lies), where does that put me? | 13:50 |
| Peng_ | It's using the default of 156? | 13:50 |
| Peng_ | 256* | 13:50 |
| vila | echo doesn't lie, try 'shopt' and search for checkwinsize | 13:51 |
| vila | if you do echo $COLUMNS and get something, so does bzr | 13:51 |
| Peng_ | vila: echo really does lie. $COLUMNS is not listed in "env", or Python's os.environ. | 14:00 |
| Peng_ | ...I hate computers. :P | 14:00 |
| * vila kills some more chickens | 14:02 | |
| nyu | lifeless: thanks! | 14:19 |
| === weigon_ is now known as weigon | ||
| phoenixz | fullermd: Good morning! | 15:13 |
| phoenixz | fullermd: Just finished reading the other document you wrote | 15:13 |
| phoenixz | fullermd: I have to say, still not sure on how the init-repo thing works, though it seems cool.. | 15:22 |
| dlee | Trying to use Bzr against an svn repo at http://opensource.adobe.com/svn/opensource/flex/sdk: flex/sdk is the path in it, and it's from there laid out in "trunk" layout. Read-only access requires no password, and this works with svn; but bzr insists on asking for one. | 15:57 |
| dlee | I gather that this is because bzr tries to determine layout by examining the root, but I must not have read access that far up. Is there a solution to this? | 15:58 |
| jelmer | dlee: specify the layout manually | 15:58 |
| dlee | I've tried messing with ~/.bazaar/subversion.conf but it didn't help. I may not have done that correctly. | 15:58 |
| jelmer | and disa ble the cache | 15:59 |
| dlee | Can I use bzr co/branch or do I need bzr svn-import? | 15:59 |
| dlee | The latter has a layout parameter; the former two don't I think | 15:59 |
| jelmer | you can set the layout in subversion.conf | 16:00 |
| jelmer | e.g. layout = trunk0 | 16:01 |
| dlee | The 0 is new to me :) tried without. | 16:01 |
| jelmer | it shouldn't be necessray | 16:02 |
| dlee | My subversion.conf is just the [uid] line, layout=trunk (with or without 0), and locations = http://opensource.adobe.com/svn/opensource | 16:03 |
| jelmer | dlee: you'll also need to disable the cache | 16:05 |
| jelmer | dlee: 'use-cache = False' | 16:05 |
| dlee | in subversion.conf? | 16:06 |
| jelmer | yeah, in the uuid section | 16:06 |
| dlee | Hmm...still wants a user name. | 16:07 |
| dlee | tried co and svn-import, trying to check out both trunk and just flex/sdk | 16:07 |
| jelmer | can you send it ia sigquit and see what code path is tryuoing to access the repo root | 16:07 |
| jelmer | (apologies for my spelling today) | 16:07 |
| dlee | In the debugger, but I haven't been here before... what do you want from here? | 16:09 |
| cellofellow | I need to install bzr on a Mac that I don't have admin rights too. Is there some way I can do that? | 16:10 |
| Peng_ | cellofellow: Worst case, run from source. | 16:10 |
| jelmer | dlee: 'bt' will print a backtrace | 16:11 |
| Peng_ | cellofellow: You've tried the installer, and it failed without admin rights? http://bazaar-vcs.org/MacOSXDownloads | 16:12 |
| cellofellow | Peng_: it asked for them but I didn't just click cancel and see what happened. | 16:15 |
| cellofellow | if I click cancel it doesn't continue to the install | 16:15 |
| cellofellow | source it is I guess | 16:17 |
| dlee | Trying to sift out what matters... should I be suspicious at seeing "self._cached_revnum = self.transport.get_latest_revnum()"? | 16:17 |
| cellofellow | or just don't use it, I can commit from my laptop. | 16:17 |
| dlee | Looks like it happens when bzr tries to get the latest revnum. Iirc, pasting large text chunks isn't appreciated in here, or I could paste some of the backtrace. | 16:20 |
| Peng_ | dlee: Use a pastebin. | 16:24 |
| james_w | is there a way to do a backwards merge? | 16:27 |
| james_w | use case: | 16:27 |
| james_w | shared trunk with disconnected workflow | 16:28 |
| james_w | if there is a collision in pushing to the trunk then I get told the branches have diverged | 16:28 |
| james_w | if I merge trunk then it changes the left hand history of trunk | 16:28 |
| Tak | rebase? | 16:29 |
| james_w | the "correct" way to do it is to get another copy of trunk, update it, and then merge in | 16:29 |
| james_w | but that's a faf | 16:29 |
| james_w | if I could do "bzr merge", but just put the revision parents the other way around then I could do it in one directory couldn't I? | 16:29 |
| james_w | Tak: there's no need to rebase, and in fact I don't want to | 16:30 |
| dlee | Peng_ / Jelmer: I made a pastebin - never done that before either. | 16:31 |
| Peng_ | dlee: What's the URL? | 16:32 |
| dlee | http://pastebin.com/m4e19701d | 16:33 |
| jelmer | dlee: looks like we try to open the repository root at the moment when we try to figure out the last revision number | 16:35 |
| jelmer | dlee: that's not really necessary, please file a bug | 16:35 |
| jelmer | sorry, gtg - breakfast | 16:36 |
| dlee | np and thanks | 16:36 |
| phoenixz | I have varios SVN repositories containing various implementations of one and the same inhouse developed framework. Simplified, I have repo A with the framework itself, as trunk, branches and tags, from there copied (using SVK), in repo B project B1, B2 and B3, and I have repo C with projects C1 and C2... When making updates to the framework while working in repo C, project 1, I merge those changes back to the framework in Repo A. When I have updates to the | 16:41 |
| phoenixz | framework in repo A, I merge those changes to all projects in repos B and C.. I want to change from SVN / SVK to BZR. How can I import all these works from SVN / SVK to BRZ, keeping all the histories but also keeping the abilities to merge in between the various projects? | 16:41 |
| phoenixz | I know, SVN cannot copy cross-repository, but SVK can. Which is one of the reasons why I used SVK in the first place. Now, SVK is pretty much a dead project, and I want to jump ship, BZR seems like the perfect choice for me, but I would not want to loose the ability to merge in between projects.. | 16:45 |
| jelmer | phoenixz: hi | 16:47 |
| phoenixz | jelmer: hi | 16:47 |
| jelmer | phoenixz: yes, if I understand your situation correctl bzr-svn should be able to handle that | 16:48 |
| jelmer | phoenixz: please note that you shouldn't be using the 'bzr dpush' command when attempting something like this | 16:48 |
| phoenixz | jelmer: I don't even know what dpush is or does, yet.. :) | 16:49 |
| jelmer | phoenixz: in that case, don't worry about it :-) | 16:49 |
| jelmer | phoenixz: dpush is the bzr-svn equivalent of "push but don't set svk:merge" | 16:49 |
| phoenixz | jelmer: haven't found dpush in bzr help commands.. | 16:49 |
| phoenixz | jelmer: a question here.. | 16:50 |
| phoenixz | so in subversion, I have varios projects | 16:50 |
| phoenixz | each project has a trunk, development branches and tags | 16:51 |
| phoenixz | pretty common way to work in SVN | 16:51 |
| phoenixz | I use this framework within different companies | 16:51 |
| phoenixz | for each company I have multiple projects that use that framework | 16:51 |
| phoenixz | for each company I have one SVN repository that contains the projects | 16:52 |
| phoenixz | like, /svn/companya/projecta/ (where companya is an SVN repo) | 16:52 |
| phoenixz | How do I set this up in BZR? | 16:52 |
| phoenixz | Because AFAIK, BZR has each branch being its own thing | 16:53 |
| phoenixz | there is a shared repo directory | 16:53 |
| phoenixz | where I can keep those branches together | 16:53 |
| phoenixz | so I figure, for each company, I would make a shared repository | 16:53 |
| phoenixz | and in there I would place directories for each project | 16:54 |
| phoenixz | and in those project directories, I would place the branches for each project | 16:54 |
| phoenixz | jelmer: does this make sense in BZR? or did I get it totally wrong? | 16:54 |
| dlee | Jelmer: Re: getting svn latest revno querying at repo root unnecessarily: Bug #459187 filed. | 16:55 |
| ubottu | Launchpad bug 459187 in bzr "Unnecessary request for userID/password on bzr co/branch/svn-import from svn repo" [Undecided,New] https://launchpad.net/bugs/459187 | 16:55 |
| Meths | Can bzr import from CVS? | 16:56 |
| Meths | nm, found bzr-cvsps-import | 16:58 |
| jelmer | dlee: Thanks | 17:01 |
| jelmer | Meths: you may also want to check out cvs2svn's fastexport option | 17:01 |
| jelmer | phoenixz: yeah, that should work | 17:01 |
| jelmer | phoenixz: I would recommend sticking to the standard layout for svn inside of those branch container directories | 17:02 |
| jelmer | phoenixz: because bzr-svn will automatically regonize what is a branch in that case | 17:02 |
| phoenixz | jelmer: another question.. Does BZR know if different branches are related? I suppose it does, but if I make a branch of a branch of a branch, etc etc.. will the last branch still know its related to the first one | 17:03 |
| phoenixz | ? | 17:03 |
| phoenixz | I know, noob questions.. :) | 17:03 |
| jam | Meths: or use 'cvs2bzr' from the 'cvs2svn' suite. Which will create a 'fast-import' stream, that you can import using 'bzr fast-import'. | 17:03 |
| jelmer | phoenixz: yes, it will know if different branches are related | 17:04 |
| phoenixz | jelmer: is it also possible to branch a sub directories? like, I have a project A with sub directory lib.. I want a branch of only lib, is that possible too? | 17:04 |
| jelmer | phoenixz: partial checkouts are possible but the related history with the partent branch will not be recognized | 17:06 |
| Meths | jelmer: jam: thanks. How does bzr fast-import work? bzr help fast-import isn't implemented | 17:10 |
| jelmer | Meths: you need the bzr-fastimport plugin | 17:10 |
| Meths | ah | 17:11 |
| jelmer | phoenixz: I'm out for the day. If you have more questions, please mail the list and cc me | 17:11 |
| vila | morning jam ! | 17:11 |
| phoenixz | jelmer: thanks lots for the help so far! | 17:11 |
| vila | jam: I could spend a better week-end if I could land https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832 | 17:12 |
| jam | hey vila | 17:12 |
| jam | I'm technically on vacation again today | 17:12 |
| jam | though I found a way to shrink mem by another ~50MB or so, so I can't stay away :) | 17:12 |
| vila | jam: ach, sorry again, but hey you're here again :) | 17:12 |
| jam | I'm not sure about trusting COLUMNS when isatty() is false | 17:13 |
| Tak | jelmer: btw, I figured out what the issue was with bzr-svn/subvertpy/md-bzr | 17:13 |
| vila | jam: well, the more I dig, the more I see COLUMN being set even when you don't touch it :-) | 17:13 |
| jam | certainly under 'less' you probably don't want to truncate | 17:13 |
| jam | even though Peng does | 17:13 |
| vila | Just try it in a terminal... | 17:13 |
| jam | vila: I'm pretty sure the terminal likes to set COLUMN / COLUMNS or whatever | 17:13 |
| jam | as a hint | 17:14 |
| vila | bash too | 17:14 |
| jam | vila: well bash has to get it from the terminal, rigth? | 17:14 |
| Tak | I wasn't invoking PyEval_InitThreads | 17:14 |
| jam | or perhaps it uses SIGWINCH, or TIO or whatever | 17:14 |
| vila | I dunno, surely they talk to each other, but that makes it even more reliable | 17:14 |
| jam | vila: right, and my point is if I do "bzr XXX > file" | 17:15 |
| jam | should it be paying attention to that? | 17:15 |
| jam | also note that for our purposes | 17:15 |
| jam | sys.stderr.isatty is probably more relevant | 17:15 |
| jam | I don't think we ever truncate stdout | 17:15 |
| jam | vila: can you verify that last statement? | 17:15 |
| vila | let's not open more cans than necessary.... | 17:15 |
| vila | log --line is one know truncate case | 17:16 |
| jam | (stdout being valuable information that the command is generating, versus 'progress' etc information that can be truncated on a whim) | 17:16 |
| jam | vila: so my direct preference is "revert the 'bugfix" | 17:16 |
| jam | my second preference is "just set it to 256" | 17:16 |
| jam | my third is 'lets have a discussion and actually get this right" | 17:17 |
| vila | setting to 256 when using a tty is bad, I know that for sure | 17:17 |
| vila | ok, so I'll revert the offending revnos and wait more feeedback on the patch | 17:17 |
| Peng_ | jam & vila: <3 | 17:18 |
| jam | vila: but isatty() is False | 17:18 |
| jam | Or am I missing something | 17:18 |
| vila | jam: ECONTEXT | 17:18 |
| jam | (11:16:57 AM) vila: setting to 256 when using a tty is bad, I know that for sure | 17:19 |
| jam | You are setting it to 256 when "isatty()" is returning false | 17:19 |
| vila | yes | 17:19 |
| jam | hence "using a tty" but the system is telling us you aren't | 17:20 |
| vila | I was replying to: <my second preference is "just set it to 256"> | 17:20 |
| jam | vila: I'm saying "set it to 256 when isatty() is False" | 17:20 |
| jam | I should have typed it all out, I guess | 17:20 |
| vila | ha ok, yes, that's what the patch does | 17:20 |
| jam | I was trying to say "change 65536 => 256" | 17:20 |
| jam | vila: and a bunch of other stuff | 17:20 |
| jam | My point is there is a one line 65536 => 256 change | 17:21 |
| jam | that seems to cover what you really need | 17:21 |
| vila | haaaa, I started with that, but them I realized there was other problems and that wasn't enough | 17:21 |
| vila | s/them/then/ | 17:21 |
| vila | so, it's either, revert or fix them all | 17:22 |
| vila | well, for some values of all... | 17:22 |
| jam | vila: which is my point about (3) | 17:23 |
| jam | if we are going to spend significant time on it, lets do it the right way | 17:23 |
| jam | (and i feel stuff like checking sys.stderr is part of that, possibly handling SIGWINCH, possibly a few things) | 17:23 |
| vila | jam: ok, I thought I did that but by all means, let's discuss it widely :) | 17:24 |
| jam | $COLUMNS concerns me, because doing something like: | 17:24 |
| vila | wow, wow, wow :) | 17:24 |
| jam | bzr log --line > file | 17:24 |
| jam | seems like it shouldn't truncate | 17:24 |
| jam | should bzr log --line | less? | 17:24 |
| jam | should we truncate a progress bar, but not log --line | 17:24 |
| jam | ? | 17:24 |
| vila | yeah, the truth is I started thinking COLUMNS wasn't set behind my back but *always* by the user, I'm less sure about that now | 17:25 |
| jam | vila: well if you resize your window | 17:26 |
| jam | COLUMNS is usually updated to match | 17:26 |
| jam | it just isn't updated 'on-the-fly' while the program is running | 17:27 |
| jam | hence SIGWINCH | 17:27 |
| vila | I thought you had to use termios, not COLUMNS for that... It appears I was wrong (still not completely sure, try:) | 17:27 |
| vila | try: env| grep COLUMNS | 17:28 |
| vila | then echo $COLUMNS | 17:28 |
| vila | then under python look at os.environ['COLUMNS'] | 17:28 |
| === beuno is now known as beuno-lunch | ||
| jam | vila: I'm currently on Windows, which has fairly fixed column width for cmd.exe | 17:32 |
| jam | I can try it, I suppose | 17:32 |
| jam | echo "$COLUMNS" is empty for me | 17:33 |
| vila | Ach, windows, yeah, I have some pending questions there too... as pointed in some bugs bzr behaves differently wrt redirections on windows and linux... | 17:34 |
| jam | vila: well, there you have to also worry about '\r\n' and setmode(binary) etc. | 17:35 |
| vila | jam: on OSX: http://paste.ubuntu.com/299876/ | 17:37 |
| jam | vila: pretty | 17:37 |
| jam | I like how it ends in a frown | 17:37 |
| vila | hehe | 17:38 |
| vila | on jaunty: http://paste.ubuntu.com/299877/ | 17:38 |
| jam | hmm. same result | 17:38 |
| vila | yup | 17:38 |
| vila | on FreeBSD: http://paste.ubuntu.com/299879/ | 17:40 |
| vila | some result too, except when set by the user, COLUMNS is not seen by python... | 17:40 |
| vila | I suppose *bash* knows about COLUMNS in some kind of way | 17:40 |
| Peng_ | Oh, good, my weird results aren't unique. | 17:51 |
| jam | vila: go start enjoying your weekend | 17:56 |
| jam | :) | 17:56 |
| vila | jam: yeah, revert sent to pqm, I'll poke babune later :) | 17:57 |
| vila | jam: thanks, enjoy yours too when you decide it :) | 17:57 |
| === beuno-lunch is now known as beuno | ||
| jfroy|work | jelmer: ping-a-pong | 18:43 |
| === cellofellow is now known as undefined | ||
| === undefined is now known as Guest33850 | ||
| === Guest33850 is now known as cellofellow | ||
| Tak | if I set a command's outf to something other than stdout, will the file be closed automagically when the command is gced or no? | 19:18 |
| Tak | hmm, it looks like "no" | 19:23 |
| === thunderstruck is now known as gnomefreak | ||
| bialix | fullermd: ping | 19:55 |
| === asac_ is now known as asac | ||
| Kmos | hi | 20:31 |
| Kmos | kmos@kmos:~/packages/apport$ bzr push lp:apport | 20:31 |
| Kmos | bzr: ERROR: Cannot lock LockDir(lp-46086288:///~apport-hackers/apport/trunk/.bzr/branchlock): Transport operation not possible: readonly transport | 20:31 |
| RenatoSilva | If I cerate an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and merge all-features into trunk, will only the new commits CONFLICT_N be merged from all-features into trunk? | 20:31 |
| Kmos | break-lock doesn't work | 20:31 |
| RenatoSilva | * If I create an all-features branch with trunk + each feature branch, and commit fixes due to logical conflicts and tag them as CONFLICT_N, and merge each feature branch into trunk, and then merge all-features into trunk, then will only these new commits CONFLICT_N be merged from all-features into trunk? | 20:32 |
| Kmos | RenatoSilva: don't repeat yourself | 20:32 |
| RenatoSilva | Kmos: Strictly speaking, I didn't ;) | 20:33 |
| === dorins_ is now known as wave | ||
| Tak | hmm, if I have something in ~/.bazaar/plugins that I have a different version installed systemwide, will my local plugin override, or will there be a conflict? | 21:10 |
| lifeless | local wins | 21:20 |
| Tak | thanks | 21:27 |
| === MTeck-ricer is now known as MTecknology | ||
| james_w | hi lifeless | 22:18 |
| lifeless | hi | 22:18 |
| james_w | thanks for making the changes | 22:18 |
| james_w | I haven't reviewed the incremental diff, but I don't foresee any problems | 22:19 |
| james_w | I just replied before seeing the mail that you had made them | 22:19 |
| lifeless | ok | 22:20 |
| lifeless | so I made the bits *I* consider a must given the things the review discussion uncovered | 22:20 |
| lifeless | I haven't change print to mutter, or other such things | 22:20 |
| james_w | as I said, I'm happy to take over if you are willing to block on me | 22:20 |
| lifeless | Well, I'm running from a homedir install now | 22:21 |
| lifeless | not going to block regardless | 22:21 |
| james_w | but as you are asking me to maintain the code I am wary of merging it with things that I can see being problematic | 22:21 |
| lifeless | so, I don't think there are things remaining that are problematic, just differnet | 22:21 |
| lifeless | with the sole exception of the oauth file | 22:21 |
| lifeless | and I think that all of that should be in launchpadlib *anyway* | 22:22 |
| lifeless | its fugly the way the setup stuff is cargo culted around | 22:22 |
| james_w | I pointed to the API for that | 22:22 |
| === wave is now known as testlongnick | ||
| james_w | did you take a look at whether it matched? | 22:22 |
| lifeless | no, its saturday ;P | 22:23 |
| lifeless | and I don't understand enough to know if it matches or not. | 22:23 |
| james_w | fair enough | 22:23 |
| lifeless | the whole launchpadlib thing is rather opaque to me | 22:23 |
| lifeless | the pydoc is epic epic epic fail | 22:23 |
| lifeless | and the total inability to work and test with it offline (Without a multi-hundred mb separate download & apache locally) is a real disincentive to learn more | 22:24 |
| lifeless | so there is also a bit of passive resistance to learning more:P | 22:24 |
| james_w | pydoc launchpadlib.launchpad | 22:25 |
| james_w | /login_with | 22:25 |
| james_w | if you are interested | 22:25 |
| lifeless | heh | 22:25 |
| lifeless | so this is actual code and documented ;) | 22:25 |
| lifeless | so, login_with looks fine, but given that I know nothing about the failure modes, internals, required facilities, expected conventions... | 22:27 |
| james_w | the only issue with it is that it puts the cache in "launchpadlib_dir" | 22:27 |
| lifeless | my approval doesn't mean much | 22:27 |
| james_w | and currently the cache is broken with multiple processes | 22:28 |
| lifeless | Oh, I really hate the cache | 22:28 |
| lifeless | it shouldn't need one. | 22:28 |
| james_w | because? | 22:28 |
| lifeless | Damn silly idea, HTTP caches are extremely hard to get right. | 22:28 |
| lifeless | build the API by introspecting the wsdl and compiling python from it; then ship the resulting static API, which is fully documented and faster | 22:29 |
| lifeless | I say HTTP caches are hard to get right after years as squid-core :), its an informed opinion. | 22:29 |
| lifeless | also, if you need an HTTP cache for a web services API to work, the API design is broken and will perform problematically [because of cache seeding overhead at a minimum] | 22:32 |
| james_w | bug 459418 filed as due dilligence | 22:33 |
| lifeless | what else, oh, require write access means you can't use launchpadlib as a very restricted user, or [for instance] to grab backup data during system restore when nothing is mounted writable | 22:33 |
| ubottu | Launchpad bug 459418 in launchpadlib "Cache is broken with multiple processes" [Undecided,New] https://launchpad.net/bugs/459418 | 22:33 |
| lifeless | s/require/requiring/ | 22:34 |
| james_w | I can now go back to moaning about how login_with is broken with a clear conscience | 22:34 |
| lifeless | :) | 22:34 |
| james_w | anyhow, I shall make some time to merge your code at some point | 22:35 |
| james_w | thanks again | 22:35 |
| lifeless | that would be excellent | 22:35 |
| lifeless | I'd lke to be running a packaged bzr-builder | 22:37 |
| lifeless | the less string the easier to get OSA's to run the service ;) | 22:38 |
| jfroy|work | http://trac.webkit.org/changeset/50000 | 22:51 |
| jfroy|work | uuuuarg oops | 22:51 |
| * jfroy|work hides in shame | 22:51 | |
| jfroy|work | defeated by too many tabs, once agao | 22:51 |
| jfroy|work | *again. I apologize. | 22:51 |
| jfroy|work | jelmer: ok I have the weirdest problem with bzr-svn | 22:59 |
| jfroy|work | well, it seems to me that way. I have a completely clean repository with no bzr: props or revprops and no svn:mergeinfo or svk:merge props. | 23:00 |
| jelmer | jfroy|work: are you psychic? I just returned back to my computer after being away for half a day and you ask within a couple of seconds :-) | 23:00 |
| jfroy|work | and a straight bzr branch of the trunk branch in that repo yields a bazaar branch with a number of sha1 mismatch errors | 23:01 |
| jfroy|work | lol :p | 23:01 |
| jfroy|work | no, I'm pretty sure I'm not :p | 23:01 |
| jfroy|work | basically, we're migrating a project from a repo with a bunch of projects in it to a brand new repo dedicated to only one project | 23:02 |
| jfroy|work | so I 1) branched using bzr the trunk and the current active branches from the old svn repo 2) pushed trunk (with the push merged revision option enabled) to a simulation blank svn repo 3) dumped that 4) ran a filter on the dump to strip every revprop and prop starting with bzr: (as well as svn:mergeinfo and svk:merge) 5) loaded that filtered dump into a new repo and 6) branched the trunk from that repo | 23:04 |
| jelmer | did you change the UUID or throw away the cache? | 23:04 |
| jfroy|work | that should yield a clean bzr branch, shouldn't it? | 23:04 |
| jfroy|work | pretty sure I did | 23:04 |
| jfroy|work | ~/.bazaar/svn-cache/ and ~/.bazaar/subversion.conf | 23:05 |
| jfroy|work | And I get a "Initialising Subversion metadata cache" message when branching | 23:05 |
| jfroy|work | I'm guessing the only thing left that could trip bzr-svn are copy nodes it's trying to interpret | 23:06 |
| jfroy|work | I don't think there's anything that can be done about those | 23:06 |
| jelmer | can you reproduce the problem on a small repo? | 23:07 |
| jfroy|work | I have no idea how to reproduce this | 23:08 |
| jfroy|work | oi, wait a second... | 23:09 |
| jfroy|work | these are the sha1 mismatches | 23:10 |
| jfroy|work | http://paste.ubuntu.com/300096/ | 23:10 |
| jelmer | can you pastebin the backtrace? | 23:10 |
| jfroy|work | no backtrace | 23:10 |
| jfroy|work | this is output by bzr check | 23:11 |
| jfroy|work | All of those files are symbolic links | 23:11 |
| jfroy|work | I think this is the problem | 23:11 |
| jelmer | ah, that might make sense | 23:11 |
| jelmer | That should be a relatively trivial bzr-svn bug | 23:11 |
| jfroy|work | those 4 files are all empty with Property svn:special set to * | 23:11 |
| jfroy|work | and the content set to "link Versions/Current/ATF" | 23:12 |
| jelmer | we're just filling in a different sha1 in the inventory as we put in the versionedfiles | 23:12 |
| jfroy|work | s/ATF/foo | 23:12 |
| jelmer | jfroy|work: can you file a bug? | 23:12 |
| jelmer | jfroy|work: :-) | 23:12 |
| jfroy|work | let me try to repro with a simple repo | 23:12 |
| jelmer | jfroy|work: I have some long flights coming up, might give me something to do :-) | 23:13 |
| jfroy|work | That would be incredibly awesome :) | 23:13 |
| jfroy|work | yup | 23:17 |
| jfroy|work | reproduced with a one commit repo | 23:17 |
| jfroy|work | jelmer: https://bugs.launchpad.net/bzr-svn/+bug/459440 | 23:22 |
| ubottu | Launchpad bug 459440 in bzr-svn "bzr-svn sha1 mismatches on symbolic link files" [Undecided,New] | 23:22 |
| jelmer | jfroy|work: awesome, thanks | 23:23 |
| jfroy|work | jelmer: oh, I've found another minor issue | 23:26 |
| jfroy|work | if you create a brand new repo and push a branch to <repo url>/trunk, you won't get any tags (but branches will show up if you have push merged revisions) | 23:27 |
| jelmer | jfroy|work: please file a bug for that one as well | 23:27 |
| jelmer | jfroy|work: and thanks :-) | 23:27 |
| jfroy|work | if, however, you create a revision 1 with svn that creates the standard layout, then push --overwrite, then you'll get tags | 23:27 |
| jfroy|work | I'm guessing it doesn't detect that the repo is using the standard layout | 23:28 |
| jfroy|work | probably needs a "repo is at revision 0, I should make the standard layout first" special case | 23:28 |
| jelmer | I suspect it's because we have a different code for "create this branch" vs "push revisions to this existing branch" | 23:29 |
| jfroy|work | https://bugs.launchpad.net/bzr-svn/+bug/459444 | 23:33 |
| ubottu | Launchpad bug 459444 in bzr-svn "Pushing to a blank repository does not push tags" [Undecided,New] | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!