| simony | local, but I had a bind to a remote non-responding server | 00:01 |
|---|---|---|
| simony | I tried making a bundle with a remembered location of that server, and then to break lock when that hung, also hung, possibly because I was still bound | 00:01 |
| abentley | lifeless: ping | 00:05 |
| igc | bbiab | 00:07 |
| lifeless | abentley: pong | 00:22 |
| jamesh | morning lifeless | 00:23 |
| lifeless | hi jamesh, nice to see you hacking on bzr desktop stuff :) | 00:23 |
| abentley | I am confused by a comment you added to KnitVersionedFile._get_content_maps. It's the one that begins with FUTURE | 00:23 |
| lifeless | abentley: paging in | 00:23 |
| jamesh | lifeless: I'm about half way through redoing bzr-avahi | 00:23 |
| lifeless | abentley: right, its about avoiding memory pressure and copying | 00:23 |
| abentley | It looks like the suggestion has already been done, and was done in the same commit. | 00:24 |
| abentley | Oh, I see. | 00:24 |
| abentley | It's about tracking it on a per-component level. | 00:24 |
| lifeless | right | 00:24 |
| lifeless | compent X may be needed for 400 children | 00:25 |
| abentley | Rather than just having the multiple_versions toggle. | 00:25 |
| lifeless | yeah | 00:25 |
| lifeless | ideally if we extract two texts at once with no common components no component should be copied | 00:26 |
| lifeless | and two texts with X components in common - a Y shape tree - we should not copy any of the X common components, only the single point at which it bifurcates | 00:26 |
| abentley | One issue I'm trying to sort out is how to handle memory pressure in iter_files_bytes. | 00:31 |
| abentley | Even if you get rid of components as soon as you don't need them, you can still wind up with old fulltexts for all the files in memory at once. | 00:32 |
| jamesh | lifeless: I don't know if it is relevant to your bzr-dbus plugin, but I got bzr-avahi broadcasting signals over the session bus without a central daemon (other than the session bus itself) | 01:17 |
| jamesh | lifeless: maybe you could use something like that to simplify bzr-dbus? | 01:17 |
| lifeless | jamesh: possibly; actually I want to have the central service provide a recent-history list | 01:18 |
| jamesh | ah. | 01:18 |
| jamesh | lifeless: for bzr-avahi, the use case was to notify any interested server processes when changing the "advertised" state of a branch | 01:19 |
| jamesh | in which case a simple signal broadcast fit well | 01:19 |
| lifeless | yah | 01:20 |
| lifeless | it may be overengineering of course | 01:21 |
| lifeless | abentley: re memory pressure - indeed; this is why I think we may not want to optimise for IO performance over everything else; find a balance. | 01:21 |
| lifeless | abentley: we know how big the components are; so we can say 'up to X MB in memory at once', and plan extractions that only exceed that when they have to (ISO's anyone) | 01:22 |
| abentley | Good idea. That should be reasonably easy to achieve. | 01:24 |
| lifeless | spiv: ping | 01:48 |
| lifeless | abentley: its tricky figuring out how much memory is reasonable, I would say 50MB or so of components? | 01:48 |
| lifeless | abentley: or even 10MB is enough to massively reduce round trip latency | 01:49 |
| abentley | Yeah, those numbers are okay. | 01:50 |
| abentley | I'm planning to start with a version that just assumes infinite memory, and then tune it. | 01:51 |
| abentley | but 50 MB about the size of the Bazaar repository. | 01:52 |
| lifeless | abentley: I'd like to write a hook for people wanting to do \r\n conversions, and $Id$ conversions | 02:34 |
| lifeless | abentley: Do you think its reasonable for us to have a single API point for writing-to-a-tree-file and reading-from-a-tree-file ? | 02:35 |
| lifeless | abentley: I'm thinking a chain of filters, each of which has an 'in' and 'out' direction, that respectively adds/removes the filters changes. | 02:36 |
| lifeless | abentley: and presumably a reference to $configuration data to determine when to operate | 02:36 |
| abentley | That sounds pretty reasonable. | 02:50 |
| abentley | We currently have a wacky set of overlapping file read functions. | 02:52 |
| abentley | TreeTransform does most of the file writing, but I think there are some exceptions, like .bzrignore. | 02:53 |
| abentley | It would be nice to avoid invoking the filters for files to which they don't apply. | 02:55 |
| abentley | Rather than having the filters themselves determine that. | 02:55 |
| abentley | I don't know if there would be significant performance degredation for files that needed no filtering. Perhaps we wouldn't notice. | 02:56 |
| lifeless | so I am thinking that the default is no filters present | 03:14 |
| lifeless | and tree transform etc would do a single lookup to get the callables/object to use for a given tree, so that will in the case of no filters be identical performance to now | 03:15 |
| fullermd | Might you need some add'l logic in dirstate to properly catch [un]changes? | 03:16 |
| lifeless | avoiding invoking the filters for some files seems like an abstraction violation to me | 03:16 |
| lifeless | fullermd: dirstate will have to work with this yes, in particular it needs to see the filtered version for a given sha1 etc | 03:16 |
| lifeless | fullermd: and turning on a filter for an existing tree needs care | 03:16 |
| lifeless | it will be a tree format bump at a minimum to do this AFAICT | 03:17 |
| fullermd | Could be some trickiness in there too. | 03:18 |
| fullermd | Like if I had an $Id$ in the file, and manually collapsed it. | 03:18 |
| lifeless | fullermd: yes, but if you are insane enough to want $Id$ support, you get what you deserve. | 03:19 |
| fullermd | :P | 03:19 |
| lifeless | spiv: ping | 03:25 |
| poolie | spiv, ping :) | 03:28 |
| poolie | spiv, can you make that protocol update doc public somewhere? | 03:28 |
| spiv | poolie: ok, on phone with lifeless atm :) | 03:30 |
| poolie | haha | 03:30 |
| mlh | poolie: I think your1.2 release rc mail was truncated | 03:51 |
| poolie | hm | 03:51 |
| poolie | it left here ok | 03:52 |
| poolie | oh i see, just the last sentence | 03:55 |
| mlh | yar | 03:56 |
| mlh | To get them ... out on time? | 03:57 |
| mlh | Just mentioning it in case there was a chunk left off | 03:57 |
| lifeless | jamesh: was my gnome-gpg patch correct? | 04:07 |
| jamesh | lifeless: I didn't get round to checking it out last week (busy at LCA). I'll do so this week though | 04:08 |
| lifeless | no worries | 04:08 |
| jamesh | I ran into this bzr bug last week: https://bugs.edge.launchpad.net/bzr/+bug/86838 | 04:09 |
| ubotu | Launchpad bug 86838 in bzr "locations.conf gets rewritten, dropping necessary quotes" [Undecided,New] | 04:09 |
| jamesh | was a bit puzzling | 04:09 |
| jamesh | on mDNS naming conflicts, I was trying to write the new name for the branch from "foo" to "foo #2" | 04:10 |
| jamesh | and reading that config value back gave "foo" ... | 04:10 |
| poolie | that sounds bad, though maybe a configobject bug | 04:11 |
| lifeless | eek | 04:11 |
| jamesh | the configuration file does seem to retain the trailing comment though | 04:11 |
| jamesh | so on the next loop it rewrote the config to "mdns-name = foo #2#2" | 04:12 |
| jamesh | etc. | 04:12 |
| lifeless | rotfl | 04:12 |
| === mtaylor is now known as mtaylor|zzz | ||
| abentley | spiv: ping | 05:06 |
| spiv | abentley: pong | 05:06 |
| abentley | Could I get your opinion on the Storage API I proposed? I'd like your opinion on whether it's a reasonable minimum API for remote repositories. | 05:07 |
| Nephyrin | And that's how you know when you're on freenode. | 05:08 |
| spiv | abentley: I'll take a look | 05:09 |
| abentley | Thanks. | 05:09 |
| Peng | Hmm, what happens if a remote branch gets updated while pulling? | 05:11 |
| abentley | Peng: You get a correct copy of the branch before it was updated. | 05:11 |
| Peng | Oh, cool. | 05:12 |
| Peng | I think "import bzrlib.lazy_import" imports 30 more things in 1.1 than it did in 0.90 or 1.0 or whatever I had before. How nice. :P | 07:26 |
| === mtaylor|zzz is now known as mtaylor | ||
| mtaylor | Peng: lazy_import does a really good job of confusing editors that are IDE's and parse the code, too :) | 08:00 |
| jamesh | https://bugs.edge.launchpad.net/bzr/+bug/188855 <- MemoryTransport.list_dirs() seems busted | 08:05 |
| ubotu | Launchpad bug 188855 in bzr "BzrDir.find_branches() goes into an infinite loop on MemoryTransport" [Undecided,New] | 08:05 |
| ubotu | New bug: #188855 in bzr "BzrDir.find_branches() goes into an infinite loop on MemoryTransport" [Undecided,New] https://launchpad.net/bugs/188855 | 08:05 |
| Peng | mtaylor: Heh, yeah. It confuses my more basic text editor's auto-indendation too. | 09:25 |
| Peng | Mercurial's demandimport is better there. It replaces __import__ so it intercepts all imports and you can use the regular import statement. | 09:27 |
| Peng | Importing just it also doesn't import half the stdlib. :\ | 09:27 |
| Peng | Not all modules can be imported lazily, so it has to keep a blacklist though. | 09:28 |
| Peng | But it does save on code, since it doesn't have to parse the string of import statements lazy_import does. | 09:29 |
| spiv | Hmm, just "import bzrlib.lazy_import" it does seem to import 52 modules. | 09:42 |
| spiv | Which does seem a touch high.. | 09:43 |
| Peng | Thanks to bzrlib.__init__. | 09:44 |
| Peng | ISTM it imports either 70 or 100 other modules. | 09:44 |
| spiv | And bzrlib.errors | 09:44 |
| Peng | It only lazy-imports bzrlib.errors. | 09:45 |
| Peng | Isn't the email module in stdlib supposed to have a working lazy-importer? | 09:46 |
| * spiv foods | 09:46 | |
| Peng | (It lazy-imports its submodules since they apparently all import each other.) | 09:47 |
| Peng | Ohh, it does work. It just doesn't prevent the AttributeError the first time one tries to access a submodule. | 09:47 |
| Peng | But it works the second time. | 09:47 |
| Peng | That's not so useful. | 09:47 |
| Peng | email's LazyImporter is precisely 9 lines long. But if it doesn't work, I guess that doesn't mean much compared to the 200 lines bzr uses and the 50 or 75 lines hg uses. | 09:51 |
| Peng | (Not counting setup code.) | 09:51 |
| poolie_ | hm | 09:55 |
| poolie_ | Peng, hg's approach is reported to cause problems for other programs trying to import it | 09:56 |
| poolie_ | there is one idea we could take from email.py, which would be to explicitly know about all submodules, and create their importers in bzrlib at load time | 09:57 |
| poolie_ | i'm not sure if this would be very practical | 09:57 |
| mwhudson | hg's interfere's with hg's own setup.py last i checked :) | 09:58 |
| * mwhudson zzz | 09:58 | |
| Peng | Bzr is way too large, and still rapidly-evolving, to do that. | 09:58 |
| poolie_ | mm | 09:58 |
| Peng | mwhudson: Oh, is that the reason easy_install doesn't work with it? | 09:58 |
| poolie_ | i think we add modules rarely enough that having a list in bzrlib/__init__ would be ok | 09:58 |
| poolie_ | however, i think it would mean everything had to be referenced through fully-qualified names, which would be tedious | 09:59 |
| Peng | Would you list all modules recursively, or just the top-level ones? | 09:59 |
| poolie_ | i hadn't got that far | 09:59 |
| === poolie_ is now known as poolie | ||
| poolie | do you think it could work even for top level mods/ | 09:59 |
| Peng | As of 1.1, there are 121 top-level ones and 558 total, not counting the 4 or 5 C ones. | 10:00 |
| Peng | That can't be right. | 10:01 |
| Peng | Yeah, it is. | 10:01 |
| Peng | Yikes. | 10:01 |
| spiv | Peng: Hmm, with a bit of hackery here, I can get the number of imports caused by "import bzrlib.lazy_imports" down to 43. | 10:04 |
| spiv | Still not quite as quick on "bzr --no-plugins rocks" as the 0.92 version in my /usr/bin/, though. | 10:06 |
| Peng | I was just using it in a random script I hacked together for one module, so that's still about 42 modules more than I'd like. :P | 10:06 |
| poolie | what were you calling in bzrlib? | 10:08 |
| Peng | Nothing. | 10:09 |
| Peng | I think lazy_import is neat and just wanted to use it. :) | 10:09 |
| asac | hey ... if a branch is locked like "locked 176 hours, 7 minutes ago" ... how can i resolve it manually? | 10:26 |
| asac | (doing a push) | 10:26 |
| quicksilver | bzr break-lock, or something | 10:26 |
| quicksilver | I thought there was a hint in that message telling you, actually | 10:27 |
| asac | what location to use? | 10:27 |
| asac | http://paste.ubuntu.com/4161/ | 10:27 |
| asac | e.g. Usage: bzr break-lock [LOCATION] | 10:28 |
| quicksilver | the location of the branch which has a lock? | 10:28 |
| asac | yep works | 10:29 |
| asac | thanks | 10:29 |
| zurgutt | is it documented somewhere what happens if one has several repositories on one work tree? | 10:57 |
| awilkins | Do you mean nested trees? | 10:57 |
| zurgutt | i guess so | 10:57 |
| awilkins | I have an interest but I've not had time to experiement with it | 10:58 |
| zurgutt | cd root;bzr init;cd subdir_under_root;bzr init | 10:58 |
| awilkins | http://bazaar-vcs.org/NestedTrees | 10:58 |
| dato | zurgutt: but, are they independent? | 10:58 |
| zurgutt | i expected for it to work transparently, meaning the two branches should not get in eachothers ways, but seems that outer branch does not "see" into inner one | 10:59 |
| dato | you just have to take care of not "adding" inner into outer, and it should work? (that is, they'll be completely independent) | 11:00 |
| zurgutt | that means every file created in inner must be explicitly added, recursion doesnt work | 11:00 |
| zurgutt | ? | 11:00 |
| awilkins | Ah, so if is issue "bzr add outer", you want it to also imply "bzr add inner" ? | 11:01 |
| dato | what I mean is: "if you want outer to know nothing about inner (that is, inner could as very well be somewhere else), that works. if you want for outer to know about inner, that's nested trees, what awilkins said." afaik, anyway. | 11:02 |
| zurgutt | basicly its web tree of a big project, i want to have one repo for "everything" as kind of archive and separate ones for subtrees, for speed and convenience | 11:02 |
| awilkins | zurgutt: You can use the same repository to store a whole bunch of branches and use something to manage how you check them out? | 11:10 |
| zurgutt | not what i look for i think, how do i describe it.. ok very basicly - can one file in a work tree belong to 2 different branches at same time? | 11:14 |
| johnny | describe the use case? | 11:17 |
| zurgutt | cd /webroot/subsite;bzr init;bzr add;bzr commit ; cd /webroot;bzr init;bzr add;bzr commit - now if i add a file in /webroot/subsite i would expect cd /webroot;bzr add;bzr commit would include and version that file | 11:22 |
| zurgutt | what DOES seem to happen is bzr in /webroot does not seem to see any changes in /webroot/subsite anymore | 11:22 |
| johnny | it shouldn't | 11:24 |
| lostylost | I have a question: What would happen in the scenario where I have created some changes in the working tree of a bound branch, then run update before doing a local commit. What happens to my changes are they overwritten? | 11:24 |
| zurgutt | johnny: what do you mean | 11:24 |
| johnny | i mean.. it should | 11:25 |
| johnny | that's expected behaviour atm prolly | 11:25 |
| dato | lostylost: no, they will be retained. *maybe* there will be conflicts, at most. | 11:25 |
| lostylost | ok cheers | 11:25 |
| lostylost | I figured as much, just wanted to be clear | 11:25 |
| zurgutt | johnny: ok, if i run a test case and pastebin the console log, can you look at it? | 11:26 |
| johnny | i prolly wouldn't be the best person to answer | 11:27 |
| johnny | but by looking at what you said, and then looking at the nestedtree doc | 11:27 |
| johnny | it seems like that is how it should work | 11:27 |
| zurgutt | can you give url to doc you mean, i tried to look it up but ones i found did not have much info | 11:28 |
| johnny | somebody already did | 11:28 |
| johnny | they said you have to use configmanager, there is no in bzr support for nested tree | 11:29 |
| zurgutt | configmanager appears to be tool to deploy files from separate branches into one tree, what i am looking for is the reverse process | 11:46 |
| johnny | it doensn't exist | 11:47 |
| johnny | afaik | 11:47 |
| johnny | wait for a few hours and ask again i guess | 11:47 |
| zurgutt | thats strange because it would not need any extra functionality whatsoever and just seems to be arbitrarily blocked | 11:48 |
| johnny | i know many vcs don't support it | 11:48 |
| johnny | so tha'ts not the case | 11:48 |
| zurgutt | see the example in http://pastebin.ca/891133 , can anyone tell why this happens? | 11:54 |
| Peng | zurgutt: That would be horribly confusing. | 12:01 |
| Peng | zurgutt: Should the higher-up branch version the .bzr directory of the lower one too? | 12:01 |
| zurgutt | how come? | 12:02 |
| zurgutt | no of course not, it should not touch . dirs | 12:02 |
| zurgutt | every branch should just see normal file tree under it | 12:03 |
| Peng | How is the lower branch related to the upper one? If you do "bzr log" for the upper one, should it show the lower one's log too? | 12:05 |
| Peng | If you commit a change in the lower one, you'd have to also commit it in the upper one. | 12:05 |
| zurgutt | neither branch should not be aware of other one | 12:06 |
| zurgutt | so yes, change in sub would need separate commit in sub and the container | 12:08 |
| Peng | That would be horrible. | 12:09 |
| zurgutt | why? | 12:09 |
| zurgutt | i see no problem whatsoever and nice possibilities of granulation | 12:10 |
| Peng | You'd have to remember to commit twice for every change you make, copying and pasting the commit message or rewriting it or something. | 12:11 |
| Peng | Now that you mention granulation, something like this would be useful, but I think doing it this way would definitely not be worth it. | 12:12 |
| zurgutt | not necessarily, these repos would not necessarily be committed in sync, in fact in my case idea was to commit the sub often between developers and the containing folder once a day or so, for general archive of whole project. | 12:13 |
| zurgutt | very neat and useful | 12:13 |
| Peng | Why? | 12:15 |
| Peng | Meh, never mind on the "Why?". | 12:15 |
| Peng | Having a shorter summary could be useful, but going about it this way isn't right. | 12:16 |
| zurgutt | Why? | 12:16 |
| zurgutt | Currently this possibility has been artifically blocked, withou it giving any benefit. | 12:16 |
| Peng | The benefit is lack of confusingness. | 12:17 |
| Peng | FWIW, in bzr, when you merge a branch, you have to commit the merge, and you can provide a summary. "bzr log" will show the merged revisions indented. | 12:17 |
| zurgutt | There is no confusion. It is not the place of bzr to care what tools are used to change the source files right? So why would it block using bzr itself? | 12:19 |
| Peng | For one thing, that's throwing away history. | 12:24 |
| * Peng shrugs. | 12:24 | |
| Peng | I suck at arguing.\ | 12:24 |
| Peng | I could lose an argument that water is wet. | 12:24 |
| zurgutt | explain? its actually keeping more history it seems to me because both sub and container keep it | 12:25 |
| zurgutt | im just trying to see the ligh, not arguing for its sake | 12:25 |
| Peng | Sure, but why shouldn't container have it too? | 12:26 |
| Peng | zurgutt: I didn't think you were arguing just for argument's sake. | 12:27 |
| zurgutt | exactly, but currently it cant becaue access to sub is blocked from it | 12:27 |
| Peng | And I should s/argue/debate/. | 12:27 |
| Peng | zurgutt: Why do you want to have a separate sub? | 12:27 |
| zurgutt | so currently the container loses all history and versioning of the sub | 12:28 |
| Peng | I'd prefer container be entirely separate than have a low-fidelity copy of sub's history. | 12:29 |
| Peng | Nested trees should solve this in some awesome way, when they're done. | 12:29 |
| awilkins | jelmer: log from win32 test of revision 904 > http://filebin.ca/bgrfkf/log.zip | 12:29 |
| Peng | On another subject, why does my tongue hurt? | 12:30 |
| muffinresearch | So are nested tree not currently finished? I thought they were available from 0.15? | 12:30 |
| zurgutt | what _are_ the nested trees? i thought what i was describing was it but apparently not | 12:31 |
| zurgutt | could not find any definition | 12:31 |
| Peng | Yeah, what you are describing is nested trees. | 12:31 |
| Peng | http://bazaar-vcs.org/NestedTree | 12:31 |
| Peng | That page also has links to two pages on what Bazaar's nested tree support will be like. | 12:32 |
| awilkins | Do a "bzr help join" ; you may find that helpful | 12:33 |
| Peng | Has join's help been updated to mention pack-0.92-subtree? | 12:34 |
| jelmer | awilkins: thanks! | 12:35 |
| awilkins | Peng: Join says "dirstate-with-subtree" | 12:37 |
| jelmer | awilkins: I've committed a fix that should take care of the executable bit errors. This should reduce the number of failures by 18. | 12:41 |
| muffinresearch | I see it's initial support: http://jelmer.vernstok.nl/blog/archives/164-Bazaar-and-Subversion-nested-tree-support.html | 12:42 |
| jelmer | muffinresearch: there is by-reference nested tree support but it is experimental | 12:44 |
| jelmer | It is probably not a good idea yet to use it in a production environment | 12:44 |
| awilkins | jelmer: I say that ; the problems are mostly errors in the tests either down to Windows or my particular environment (I get similar results on all three of my win32 machines (XP, XP, Vista) | 12:45 |
| awilkins | jelmer: *SAW that (your executable bit patch) | 12:46 |
| awilkins | There are a few things like the path being double-escaped (path looks right apart from the extra backslashes) | 12:47 |
| jelmer | awilkins: Yeah, I'm not sure yet what's causing that | 12:50 |
| awilkins | Looks like it's in Branch | 12:51 |
| awilkins | Or just Branch.__repr()__ | 12:52 |
| jelmer | it's not just the double escaping though | 12:52 |
| jelmer | it should be using forward slashes | 12:52 |
| awilkins | If it was using forward slashes, the double escaping wouldn't be a problem :-) | 12:53 |
| jelmer | it should be using forward slashes now | 12:58 |
| jelmer | that may also fix some other problems | 12:58 |
| === spiv_ is now known as spiv | ||
| === mrevell is now known as mrevell-lunch | ||
| * awilkins runs tests | 13:04 | |
| === asabil__ is now known as asabil | ||
| jelmer | awilkins: any luck? | 13:31 |
| awilkins | Still running | 13:31 |
| jelmer | wow | 13:32 |
| awilkins | Windows filesystem performance sucketh | 13:32 |
| jelmer | it usually takes around 1000s to run the tests here | 13:32 |
| awilkins | THe main reason git is so staggeringly fast on Linux is because i) The guy who did the silesystem code in the kernel wrote it and ii) Linux filesystem performance kicks the crap out of win32 | 13:33 |
| awilkins | Plus fork() is really slow on windows as well | 13:33 |
| awilkins | (it not having fork() for starters) | 13:33 |
| jelmer | what system are you on exactly? | 13:33 |
| awilkins | And these mahcines are loaded down with a ton of evilware from IT services | 13:33 |
| jelmer | the tests take a little less than twice as much time on your system | 13:34 |
| awilkins | Windows XP, P4 D 3.4Ghz | 13:34 |
| awilkins | 2GB of RAM | 13:34 |
| awilkins | It's about the same on my desktop at home, Vsita, 2.4Ghz dual core | 13:34 |
| jelmer | mine is a Core Duo 1.66 Ghz machine | 13:35 |
| awilkins | http://filebin.ca/chxdoc/log.zip | 13:35 |
| * Debolaz gave up on running git on windows. | 13:37 | |
| jelmer | awilkins: thanks. seems we've managed to fix 1 failure and 9 errors | 13:38 |
| awilkins | Just running those logs through a diff here :-) | 13:39 |
| Debolaz | Although it's still my main scm on *nix. | 13:40 |
| awilkins | I do far more windows dev than *nix | 13:41 |
| awilkins | Something that integrates nicely with SVN is also a must (git does, but I could never get it working properly) | 13:41 |
| awilkins | I have some code in Monotone, but it's not ideal | 13:43 |
| jelmer | awilkins: I've fixed a couple more issues | 13:51 |
| awilkins | Did you get the one in test_convert? | 13:51 |
| awilkins | I was just going to find it and patch it :-) | 13:52 |
| awilkins | Another one of thse "no root on windows" paths things | 13:52 |
| jelmer | yep, committing it now | 13:54 |
| awilkins | My fault, by thte looks of it, half patching it in the first place. | 13:55 |
| * abentley just got his Bazaar T-shirt in the mail | 13:57 | |
| jelmer | awilkins: ok, committed. Any chance you can run the test suite again? | 13:58 |
| jelmer | I wonder what the "Can't find parent directory's entry while trying to add ..." | 13:58 |
| jelmer | is being caused by | 13:58 |
| awilkins | How do you permanently change the default pull path? | 13:59 |
| jelmer | bzr pull --remember | 13:59 |
| awilkins | cheers | 13:59 |
| awilkins | Had it bound to the mirror | 14:00 |
| === mrevell-lunch is now known as mrevell | ||
| igc | night all | 14:01 |
| jelmer | g'night Ian | 14:01 |
| jelmer | I wonder if it's possible to get launchpad to do simple redirects rather than a full mirror | 14:02 |
| awilkins | Is that test trying to commit files to a directory that has been created but not committed to the SVN repo yet? | 14:03 |
| awilkins | Not that that seems to cause a problem : -( | 14:05 |
| jelmer | it's testing the bzr-svn support for working with Subversion working copies | 14:06 |
| jelmer | that path in the error doesn't indicate any path characters being converted incorrectly | 14:07 |
| awilkins | Is there a way to stop bzr using a proxy? | 14:07 |
| awilkins | It appears to be using my IE proxy setttings in the absence of HTTP_PROXY variable | 14:08 |
| awilkins | which is most annoying for repos inside the firewall | 14:08 |
| abentley | jelmer: I doubt it's possible to get Launchpad to redirects. Even a reference branch will get turned into a mirror, because uploads are done to a "quarrantine" area, then pulled over into the http area. | 14:08 |
| awilkins | Freeow, never knew you could go itno an svn WC and do bzr status | 14:09 |
| abentley | jelmer: btw, I'd be interested what you think of the Storage API I proposed. Would it be practical to use for bzr-svn? | 14:10 |
| awilkins | jelmer: Is going into an SVN WC and doing a "bzr status" supposed to work? | 14:12 |
| zurgutt | awilkins: thanks for "bzr help join" tip, from help it seems to be what i want, transparent | 14:16 |
| vila | awilkins: try setting the no_proxy env var instead ;) | 14:17 |
| awilkins | vila: Aha, is that a common thing, or does it just affect pycurl? | 14:18 |
| vila | pretty common, but the real solution will be to update your IE proxy settings... | 14:18 |
| zurgutt | awilkins: i dont seem to see the dirstate-with-subtree that it needs in list of formats tho | 14:18 |
| awilkins | zurgutt: It's hidden ; it should be there in v 1 (or 1.1) | 14:19 |
| vila | so that you have one place to setup right | 14:19 |
| zurgutt | tried --rich-root which makes join crash | 14:19 |
| awilkins | My trees all seem to be in that format anyway so I guess it's the default in 1.1 | 14:19 |
| awilkins | vila: IT services have a stupid little script which fubars the proxy settings every time we log in | 14:19 |
| vila | awilkins: ha ! Great ! I love these ones :-( | 14:20 |
| awilkins | jelmer: Looks like that proxy was causing my Not a Branch errors | 14:20 |
| vila | awilkins: then you must go the env var route :-/ | 14:20 |
| awilkins | Or I can stick my proxy auth details in a plain textfile in my %appdata% folder | 14:21 |
| awilkins | :_0 | 14:21 |
| zurgutt | is there a way to convert existing repo to new storage format? | 14:26 |
| awilkins | bzr help upgrade | 14:27 |
| abentley | awilkins: dirsate-with-subtree will probably never be un-hidden. | 14:28 |
| awilkins | abentley: What's it being turned into? | 14:28 |
| zurgutt | indeed its not in bzr help formats in 1.1 | 14:29 |
| abentley | It's a format that doesn't use packs, and we don't need another of those. | 14:29 |
| zurgutt | why? is it usable? | 14:29 |
| abentley | zurgutt: The format itself is fine, but the functionality it enables does not work properly. | 14:30 |
| zurgutt | ehh.. :P | 14:30 |
| awilkins | Does the server repository influence the format the client repository is when it pulls? | 14:31 |
| awilkins | Because my copy of bzr-svn is in a dirstate-with-trees repo and I didn't make any effort to say so. | 14:31 |
| awilkins | Are the features going to be written into a future packed format? | 14:32 |
| abentley | awilkins: The formats already exist. rich-root-packs and rich-root. | 14:35 |
| awilkins | abentley: Excellent.... so nested-tree jsut hasn't caught up to them? | 14:35 |
| abentley | Nested trees hasn't been under active development for almost a year. | 14:36 |
| awilkins | jelmer: http://filebin.ca/hdpoga/log.zip | 14:36 |
| awilkins | Scratched another 10kb off the log | 14:36 |
| awilkins | abentley: I figured that from the "0.15" version number on the Progress page :-) | 14:37 |
| zurgutt | weird, because there just isnt any development needed for it | 14:37 |
| abentley | zurgutt: Nested trees is not the same thing as what you were originally asking for. | 14:37 |
| zurgutt | ah, ok, someone said it was. | 14:38 |
| abentley | zurgutt: And there is plenty of work remaining to be done. | 14:38 |
| abentley | zurgutt: You wanted one file to be part of two trees. That's not supported and is unlikely to be supported. Nested trees allows whole trees to be contained as part of other trees, so that you can split a large project into pieces. | 14:39 |
| * awilkins cackles, rubs his hand toghether, and puts bzrsvn through the torture of mirroring a 13,000 revision repository with about 1.5 GB of data in it. Bwahahahaa! | 14:40 | |
| zurgutt | i tried my setup with "bzr init --rich-root-pack" and "bzr join subsite --reference" in container, which goes ok but after it "bzr add" in container will make it crash. suppose it should be reported? | 14:40 |
| awilkins | Reporting bugs is a contribution to a feature as much as anything else, but I suspect that unless one of the developers need his itch scratching it isn't getting fixed. | 14:41 |
| awilkins | Which is a shame because I'd like to see it working too :-) | 14:41 |
| awilkins | My Python is as yet undeveloped | 14:42 |
| === cprov is now known as cprov-lunch | ||
| awilkins | jelmer: Well, it ate 13,000 revisions worth of history without too many troubles, now let's see what it does with the actual data ;-) | 14:46 |
| abentley | zurgutt: Yeah, that should be reported. "bzr join subsite --reference" should not work at all in a rich-root-pack tree. | 14:47 |
| jelmer | awilkins: woot | 14:49 |
| abentley | You need "dirstate-with-subtree" or "pack-0.92-subtree" for that to work. | 14:49 |
| jelmer | awilkins: thanks for the new log | 14:49 |
| abentley | And as I've already said, the --reference functionality doesn't work properly anyhow. | 14:50 |
| jelmer | whoops, looks like I missed a few lines in my backlog | 14:51 |
| jelmer | abentley: I haven't looked at the Storage API yet - where can I find it? | 14:52 |
| jelmer | awilkins: yes, bzr status in a workign copy should work | 14:52 |
| abentley | http://bundlebuggy.aaronbentley.com/request/%3C479CF3D8.1090907@aaronbentley.com%3E | 14:52 |
| jelmer | abentley: thanks! | 14:52 |
| jelmer | abentley: It seems a little bit too low-level for the Subversion protocols | 14:55 |
| abentley | Can you give me an example? | 14:56 |
| jelmer | So, the way you retrieve the contents of a revision is to ask the subversion server for an update between revision X and Y | 14:56 |
| jelmer | (where X can be 0 for a new checkout) | 14:56 |
| jelmer | and you specify a CommitEditor object which functions get called for all of the changes | 14:57 |
| jelmer | on the protocol level, the server sends a series of commands | 14:57 |
| jelmer | "open root", "create directory", "create file", "change property", "apply delta to file" | 14:58 |
| awilkins | Those things would make a nice addition. | 14:58 |
| awilkins | Being able to ask for deltas (although rather overkill for local storage) | 14:59 |
| jelmer | afaik the fsfs backend does use a per-revision blob but that's only in their storage layer, not exposed | 14:59 |
| abentley | awilkins: A nice addition to the Storage API? | 14:59 |
| jelmer | abentley: The storage layer could be useful to support local Subversion backends without relying on the Subversion libraries, but I'm not sure I want to go there... | 15:00 |
| zurgutt | abentley: reported it. One more question and then ill be done for today:) Situation: one root dir has 2 subdirs that belong to project A and another 2 which belong to project B - how(if) is it possible to create one branch to both projects? Container can just have one branch i think. | 15:00 |
| ubotu | New bug: #188954 in bzr "add after join --reference crashes" [Undecided,New] https://launchpad.net/bugs/188954 | 15:00 |
| abentley | jelmer: So if you left out iter_raw_items, and just implemented iter_byte_streams, would that work? | 15:01 |
| jelmer | abentley: Only if I would reimplement the Subversion protocols rather than rely on the Subversion libraries | 15:03 |
| abentley | jelmer: So does bzr-svn implement iter_files_bytes? | 15:04 |
| jelmer | abentley: not at the moment. It could, but such an implementation wouldn't be very efficient | 15:05 |
| abentley | zurgutt: I wouldn't recommend using one branch for two projects. | 15:05 |
| jelmer | abentley: You can only obtain deltas or fulltexts for a complete tree rather than per file. | 15:07 |
| zurgutt | abentley: one branch per project was the idea, problem being that project does not have single container dir, there is several under one | 15:07 |
| jelmer | abentley: Supporting a Storage object in general (or perhaps a subclass of Repository that uses bytestreams?) makes sense to me though | 15:09 |
| abentley | jelmer: So how does bzr-svn construct a workingtree? | 15:10 |
| jelmer | abentley: a native svn one? It just calls out to the Subversion client library to do that | 15:12 |
| jelmer | abentley: a bzr one is created by simply calling out to bzr | 15:13 |
| abentley | jelmer: But transform.build_tree uses iter_files_bytes, so bzr-svn must be enabling it somehow. | 15:27 |
| jelmer | abentley: in which code path should it be using that? | 15:29 |
| jelmer | abentley: revert and merge are not supported in subversion working copies | 15:29 |
| jelmer | because inventory deltas are hard to apply | 15:29 |
| zurgutt | can bzr be made to work through symlinks? | 15:31 |
| abentley | For the scenario of creating a Bazaar checkout from a Subversion branch. build_tree is used by WorkingTreeFormat.__initialize__, IIRC. | 15:31 |
| === cprov-lunch is now known as cprov | ||
| === zmanuel is now known as z-man | ||
| jelmer | abentley: We never use a Bazaar WorkingTree with a Subversion Branch | 15:55 |
| jelmer | Subversion WorkingTree with Bazaar branch | 15:55 |
| jelmer | sorry | 15:55 |
| jelmer | we support Subversion WorkingTree with Subversion branch and Bazaar WorkingTree with Bazaar Branch | 15:56 |
| jelmer | there's no way to construct a bzr wt with a svn branch afaik | 15:56 |
| zurgutt | bzr add from symlinked dir also crashes :| | 15:57 |
| zurgutt | is there any documentation for configmanager? | 16:51 |
| awilkins | http://www.robertcollins.net/config-manager/trunk/HOWTO | 16:53 |
| zurgutt | nothing about usage there, nothing about bzr and very scant info on config file. have you used it, got examples? | 17:01 |
| zurgutt | i was figuring i could symlink the dirs i want in one repo into some outside dir and invoke bzr there but that does not work either :| | 17:04 |
| CardinalFang | Hi all. I'm interested in the (relatively obscure so far) per-file commit messages, and how I can add the functionality to the built-in text-editor commit. I think I have a good way of encoding it so it's obvious and minimally disruptive. I have two questions, though: | 17:50 |
| CardinalFang | 1) The text "This line and the following will be ignored" will no longer quite be true. I think putting the messages inline with the "status" output would be best. I'd rather have a message that is true for everyone regardless of whether they're ever using per-file-messages or not, and not conditional, and not confusing. Any suggestions? | 17:54 |
| CardinalFang | 1b) Also keep in mind that there may be a "diff" at the end, which should not be touched. | 17:56 |
| CardinalFang | (I realize that I used "message" to mean two different things in that question. One, warn people not to edit some parts. Two, what the user inserts. | 17:59 |
| CardinalFang | 2) There appears to be a de facto design of two-parts in the text file. A place for the user to type, delimiter, read-only stuff. Does anyone know of anything that could break if I extend it to be: A place for the user to type, delimiter, structured user-editable area, delimiter, read-only area ? | 18:02 |
| CardinalFang | There are a few parameters in functions in bzrlib/msgeditor.py that make it extensible, but seem to enforce the idea of two parts. | 18:03 |
| abentley | CardinalFang: bzr send can also use the msgeditor functionality, so it could break if you change the API. Generally, you should avoid changing the API in incompatible ways. | 18:27 |
| pcc1 | anyone here know about bzr-builddeb? is leaving the .bzr-builddeb/default.conf file in the diff.gz intentional? thanks | 18:29 |
| jelmer | pcc1: Yes, that is intentional | 18:30 |
| === Sciri_ is now known as Sciri | ||
| === cfbolz_ is now known as cfbolz | ||
| piem | hi. why is 'bzr bd' sticking .bzr-builddeb/default.conf in the .diff.gz? | 19:33 |
| jelmer | it's part of the bzr branch | 19:50 |
| pcc1 | jelmer: is this congruent with any policy? | 19:52 |
| piem | the builddeb conf has nothing to do in the .diff.gz. there is a 'def remove_bzrbuilddeb_dir', but i'm not sure it's being called in merge mode | 19:52 |
| jelmer | pcc1: not sure | 19:55 |
| jelmer | feel free to file a bug about it | 19:57 |
| jelmer | afaik it hasn't been discussed before | 19:57 |
| pcc1 | is launchpad the canonical (no pun intended) place to report bugs? | 20:04 |
| Peng | Bzr uses Launchpad for its bug tracker, yes. | 20:04 |
| dato | pcc1: bzr or bzr-builddeb? | 20:04 |
| pcc1 | bzr-builddeb | 20:04 |
| dato | pcc1: then I'd use debian's bts, the author is pretty active there | 20:05 |
| dato | (and I'm not sure there is a bzr-builddeb launchpad product) | 20:05 |
| dato | (and I could be wrong, of course) | 20:05 |
| pcc1 | dato: https://launchpad.net/bzr-builddeb but both have only 5 or 6 bugs reported | 20:05 |
| dato | ok, then your pick :) | 20:05 |
| Peng | Yay, I can pull dirstate-tags into dirstate. | 20:15 |
| AnMaster | Peng, hum? | 20:19 |
| AnMaster | why do you want plain dirstate? | 20:19 |
| Peng | Upstream is plain dirstate. | 20:19 |
| AnMaster | anyway isn't the new format "pack-0.92" or something like that iirc? | 20:19 |
| Peng | Yes. | 20:20 |
| AnMaster | or is that repo, and dirstate* is for branches? | 20:20 |
| Peng | Well, there's only one name. pack-0.92 uses the same branch format as dirstate-tags. | 20:20 |
| AnMaster | ah | 20:20 |
| Peng | I mean, you only pass one overall name to bzr upgrade or whatever. | 20:20 |
| * AnMaster uses pack-0.92 for his projects | 20:20 | |
| AnMaster | anyway I do use tags quite a bit | 20:20 |
| Peng | Well, I use the same format as upstream does. | 20:21 |
| Peng | I'd use packs and tags too, but.. | 20:21 |
| AnMaster | packs? isn't it just an internal data format? | 20:21 |
| Peng | Yeah.. | 20:24 |
| Peng | The upstream developer uses dirstate and doesn't use tags, so I'm not going to either. | 20:24 |
| * Peng wanders off. | 20:31 | |
| kjcole | Today's silly question: On a Mac, given the line-end issue, is there any plugin, patch, branch or other intelligent way to view diffs? | 20:56 |
| === jam_ is now known as jam | ||
| kjcole | (was hoping qbzr would handle such things a bit better, although the fix to handle such I expect to be elsewhere.) | 20:58 |
| mwhudson | kjcole: you still have files with \r line endings? | 21:01 |
| kjcole | mwhudson: Yep, and when I mess with that, it interferes with the program that interprets the scripts. | 21:01 |
| mwhudson | wow | 21:02 |
| mwhudson | i think bzrtools adds a --using parameter to the diff command | 21:03 |
| mwhudson | so if you have a \r-friendly diff tool, you can use that | 21:03 |
| dato | mwhudson: it's in core now | 21:04 |
| dato | (since 1.1) | 21:04 |
| kjcole | I'll check that out. (I'm a Linux guy, not enough of a Mac guy. The program in question is PsyScope, written for OS 9 (apparently) but modified enough to run natively in OS X. | 21:04 |
| mwhudson | well, i'm slightly a mac guy, and i haven't seen a \r line ending file in years :) | 21:05 |
| dato | mwhudson: it's in core now | 21:05 |
| kjcole | The issue may only be that tweaking the file removes the FileInfo, which I then manually have to set with SetFile. If I don't PsyScope chokes.) | 21:06 |
| mwhudson | dato: heard you first time :) | 21:07 |
| kjcole | It insists on wanting type = "TEXT", though I don't know if it cares at all about creator = "tach". In any case, it seems silly to change line endings just for a pretty compare. I'll look into alternate diff apps. | 21:08 |
| dato | mwhudson: irc proxy hiccup, sorry | 21:08 |
| mwhudson | ah hah | 21:08 |
| Peng | Ok, done converting dirstate-tags -> dirstate, but I still have inconsistent and sucky parent references. | 21:36 |
| igc | morning | 21:42 |
| ubotu | New bug: #162496 in bzr-svn "bzr svn advertising still a little common" [Low,Fix committed] https://launchpad.net/bugs/162496 | 21:46 |
| Peng | Oh yay, only one inconsistent parent. | 21:46 |
| Peng | Ooh, the bzr+http path issue fix needs a post-1.1 client. | 21:51 |
| Peng | Unless the server magically broke. | 21:51 |
| === Sciri_ is now known as Sciri | ||
| Skinkie | hi there... is GIT pulling now supported or not? | 22:39 |
| ubotu | New bug: #174690 in bzr-svn ""pull" should handle removal of bzr:ancestry property" [Low,Triaged] https://launchpad.net/bugs/174690 | 22:45 |
| === spiv_ is now known as spiv | ||
| spiv | poolie: https://bugs.edge.launchpad.net/bzr/+bug/185394 is that critical bug | 23:33 |
| ubotu | Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Critical,In progress] | 23:33 |
| mahmoud_ | Why Bazaar changes the default directory that Windows Command Prompt opens on ?! | 23:40 |
| rolly | It doesn't do that for me.. | 23:42 |
| mahmoud_ | rolly : It does that under vista for me | 23:42 |
| rolly | Windows XP here | 23:42 |
| * rolly tries shell-hooks in the hopes of versioning his DB schema | 23:44 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!