| Jeej | Hello | 00:07 |
|---|---|---|
| Jeej | I have a question about Bazaar | 00:08 |
| mwhudson | hi jearl | 00:08 |
| mwhudson | Jeej, even | 00:08 |
| Jeej | hi mwhudson | 00:09 |
| mwhudson | Jeej: just ask your question | 00:10 |
| Jeej | ah, well, i have just setup bazaar. I thoughed, i don't have to work in the bazaar dir, so i try it in the dir i want to use | 00:11 |
| Jeej | oh, and i use windows | 00:11 |
| mwhudson | there is a windows installer for bazaar i think | 00:12 |
| mwhudson | (i do not use windows, however) | 00:12 |
| Jeej | i found the Bazaar in five minuets document, but, now am i here: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#making-changes-to-your-files when i do bzr diff, it doesn't so anything | 00:13 |
| Jeej | yep, windows installer :-) | 00:13 |
| Jeej | So, i did bzr diff file.ex, but it gives an error: bzr: ERROR: Path(s) are not versioned: file.ex | 00:14 |
| Jeej | but i have made some changes | 00:14 |
| Odd_Bloke | Jeej: You need to have used 'bzr add' on the files, so that Bazaar knows that it should be versioning those files. | 00:15 |
| Jeej | I have done that | 00:15 |
| beuno | Jeej, how about bzr commit? | 00:15 |
| Jeej | also done | 00:15 |
| Odd_Bloke | Jeej: What does 'bzr ls --versioned' in that directory show? | 00:16 |
| Jeej | Nothing :-/ | 00:17 |
| Odd_Bloke | What about 'bzr status'? | 00:17 |
| Jeej | unknown: all the files in the dir | 00:17 |
| Odd_Bloke | Jeej: And what does 'bzr log' show? | 00:18 |
| thumper | Odd_Bloke: morning | 00:18 |
| Odd_Bloke | thumper: o/ | 00:18 |
| Jeej | can i paste it here? | 00:18 |
| Odd_Bloke | Jeej: A pastebin would be better. | 00:19 |
| Jeej | http://pastebin.com/d4d713741 | 00:19 |
| Jeej | :-) | 00:19 |
| Odd_Bloke | :D | 00:19 |
| Odd_Bloke | OK, the evidence suggests that you didn't do a 'bzr add' before your first 'bzr commit'. | 00:19 |
| Jeej | I have done that, it gave me a list of all the files in the dir | 00:20 |
| Odd_Bloke | Well, bzr clearly doesn't know anything about them any more. :/ | 00:20 |
| Jeej | Would it perhapse help when i do it now? | 00:21 |
| Odd_Bloke | Well, try it and paste the output somewhere., | 00:21 |
| Jeej | http://pastebin.com/dc6c1d85 | 00:23 |
| Odd_Bloke | Jeej: And what does 'bzr status' show now? | 00:24 |
| Jeej | still nothing | 00:24 |
| beuno | Jeej, well, are you trying to use file.ex | 00:24 |
| beuno | instead of an actual file name? | 00:24 |
| beuno | file.ex is an example name :) | 00:24 |
| Jeej | Nope, i didn't want to give you the name | 00:24 |
| beuno | Jeej, ah, right | 00:25 |
| beuno | well | 00:25 |
| beuno | try changing a file now | 00:25 |
| Jeej | But, later i though, it doesn't matter :-P | 00:25 |
| beuno | and running bzr diff | 00:25 |
| * Odd_Bloke is heading to bed. | 00:25 | |
| Odd_Bloke | Night all! | 00:25 |
| Jeej | oh, bye | 00:25 |
| beuno | night Odd_Bloke | 00:25 |
| Jeej | Woei (hehe, Dutch), it works | 00:26 |
| beuno | Jeej, :) | 00:26 |
| Jeej | well, thank you :-D | 00:27 |
| === AnMaster_ is now known as AnMaster | ||
| Jeej | i am also going to sleep | 00:30 |
| Jeej | byebye | 00:30 |
| igc | about to review abentley's PreviewTree patch now | 00:47 |
| abentley | igc: cool | 00:48 |
| igc | abentley: I'm doing that first because it's the oldest | 00:48 |
| igc | is there something higher priority of yours you want done today? | 00:49 |
| igc | either before or after that one? | 00:49 |
| abentley | Well, for that one, spiv reviewed it, but didn't actually vote. | 00:50 |
| abentley | He had some objections to the testing which I said I'd fix. | 00:50 |
| igc | just noticed that | 00:50 |
| igc | abentley: should I wait and do the fetch ones instead then? | 00:51 |
| abentley | That would be good. | 00:51 |
| igc | np | 00:51 |
| === RAOF_ is now known as RAOF | ||
| abentley | lifeless: ping | 01:32 |
| lifeless | pong | 01:36 |
| abentley | I had to tweak Repository.add_revision to munge sha1s all the time. It was only doing it when an inventory was supplied. | 01:38 |
| abentley | When I did that, I broke bundle tests. | 01:38 |
| abentley | on "/home/abentley/bzr/fetch1to2/bzrlib/bundle/bundle_data.py", line 274 | 01:39 |
| lifeless | I think that makes the api border stronger and is likely to prevent accidents; otoh perhaps asserting that the sha1 is correct when an inventory is not supplied would alter to current uses that interact badly | 01:39 |
| abentley | Should I just remove this verification? | 01:39 |
| lifeless | s/alter/alert | 01:39 |
| lifeless | I think the verification is bogus, because its asserting that the storage in the target repository format is identical to the storage in the source, but thats only the case when the model&serialisers match | 01:41 |
| abentley | Well, I think if we're going to alter sha1s in add_revision, we should expect it to happen whether or not an inventory is supplied. | 01:41 |
| abentley | But I have no way of knowing what the source serializer was for formats 0.8 and 0.9 | 01:42 |
| abentley | So I can't make that test conditional on the serializer. | 01:42 |
| lifeless | abentley: I'm completely cool with your change to add_revision; I was just making an observation that we'd catch current 'culprits' by erroring rather than just altering, when the sha1's are different | 01:42 |
| lifeless | . | 01:43 |
| * igc dentist | 01:45 | |
| abentley | Hmm. | 01:45 |
| igc | (I'll finish reviewing poolie's and jml's LockTimeout patch when I get back) | 01:45 |
| lifeless | abentley: I have no recommendation about whether altering or alerting is better. | 01:46 |
| abentley | I think I'll take altering. | 01:46 |
| lifeless | k | 01:46 |
| lifeless | so, in the bundle_data.py test, I think that has to go. | 01:46 |
| lifeless | because we don't know enough data about the origin, we can't determine what it should look like | 01:47 |
| abentley | Cool. It's only validating one field of the stored revision, which is a bit whack anyhow. | 01:47 |
| lifeless | yeah, as the comment said | 01:47 |
| poolie | hersonls: hi | 01:48 |
| abentley | So if we were to stop exposing Revision.inventory_sha1, what would we replace it with? | 01:48 |
| hersonls | poolie: hi | 01:48 |
| poolie | hello lifeless, abentley | 01:48 |
| abentley | poolie: hi | 01:49 |
| hersonls | was planning on doing slackbuild for bazaar 1.4rc, which feel about that? | 01:49 |
| hersonls | for users-tests | 01:50 |
| poolie | what do you mean by "for users-tests" | 01:50 |
| lifeless | abentley: revision.validate() or repository.validate_revision(revid) | 01:50 |
| poolie | do you mean so that users can test it? | 01:50 |
| abentley | lifeless: Would we store new data in the repo? | 01:50 |
| lifeless | abentley: I think we could in future but we could investigate whether the api would work now | 01:51 |
| hersonls | poolie: yeah | 01:51 |
| poolie | sure, that sounds good | 01:52 |
| hersonls | :) | 01:52 |
| abentley | lifeless: So we could actually stop exposing the attribute now, and just always ensure it matched its source repo. | 01:52 |
| abentley | It would be easier doing it on Repository, because it wouldn't require the revision to know its source repository. (and it may not have one) | 01:53 |
| lifeless | abentley: exactly | 01:55 |
| abentley | poolie: Sorry BB refused your vote. Not sure why yet. | 01:59 |
| poolie | abentley: i'm not sure precisely which email address i am registered with | 02:10 |
| poolie | could you tell it to accept both @sourcefrog.net and @canonical? | 02:10 |
| abentley | You've got a bunch: Submitter(id=u'Martin Pool <mbp@canonical.com>'), Submitter(id=u'Martin Pool <mbp@sourcefrog.net>'), Submitter(id=u'"Martin Pool" <mbp@sourcefrog.net>') | 02:11 |
| abentley | But it looks like you don't have "Martin Pool" in quotation marks yet. | 02:11 |
| abentley | Fixing that now. | 02:11 |
| poolie | heh | 02:11 |
| jamesh | abentley: perhaps you should extract the email address and match that? | 02:20 |
| abentley | Maybe, but email addresses aren't always unique. | 02:21 |
| abentley | poolie: I've just re-enqueued your vote. | 02:25 |
| abentley | poolie: Well, it failed, but for a legitimate reason now. | 02:28 |
| poolie | heh, what was that? | 02:28 |
| abentley | You didn't reply to the original request. | 02:29 |
| poolie | oh, replying to a reply won't do? | 02:29 |
| abentley | Not at present. | 02:29 |
| abentley | I'm trying to decide whether to use the References header, or actually record all the mail threads. | 02:29 |
| lifeless | so | 02:30 |
| lifeless | I like the current behaviour | 02:30 |
| lifeless | because I can reply to a thread with a new patch | 02:30 |
| lifeless | and there is no ambiguity | 02:30 |
| poolie | sure, that's an important case, but i think in this case there is no ambiguity about what i was reviewing either | 02:30 |
| poolie | abentley: well, at least now i know. | 02:31 |
| spiv | It's not very elegant, but maybe a "bb:review-of:<msgid>" command for a down-thread review? | 02:31 |
| poolie | spiv, at that point i think i'd just use the web ui... | 02:31 |
| abentley | poolie: There would be ambiguity if it was a long thread and I used only the references header. | 02:31 |
| spiv | Yeah, that's true. | 02:31 |
| abentley | Because the thread could have two different merge requests. | 02:32 |
| poolie | abentley: i guess i'd try using References and objecting if it's ambiguous | 02:32 |
| poolie | i suppose if you record all the messages you would be able to determine which is the closest one | 02:32 |
| abentley | Right. | 02:32 |
| abentley | Unless someone actually managed to reply to two different messages at once, which RFC2822 permits :-) | 02:33 |
| abentley | lifeless: I | 02:37 |
| abentley | I'm not sure how changing the behavior would interfere with your use case. | 02:37 |
| abentley | Perhaps you think the supersed marker is based on mail headers? It's actually based on graph ancestry. | 02:38 |
| poolie | i think an actual ambiguity of that type would be rare, to put it mildly | 02:38 |
| poolie | were you asking me? i didn't think that. | 02:38 |
| abentley | No, I was asking lifeless. | 02:39 |
| poolie | jamesh: thanks for diagnosing the bzrtools ppa problem, i'll look at it now | 02:49 |
| === mwhudson_ is now known as mwhudson | ||
| lifeless | abentley: well I was saying that without having the full graph it would be ambiguous; anyhow, you've done nice things with bb to date; I trust that any change you make will still be nice | 03:13 |
| abentley | lifeless: I agree that voting would be ambiguous if I used the References header. But creating new merge requests is never ambiguous. | 03:17 |
| lifeless | abentley: right, thats what I meant :P | 03:18 |
| lifeless | I wasn't meaning that new requests would be ambigous | 03:18 |
| lifeless | but that they could cause voting ambiguity | 03:18 |
| abentley | Ah, I misunderstood. | 03:30 |
| marnanel | This is probably a pretty stupid question, but if I want to peruse a file's version history from my own (Python) program, there are public APIs for that, right? | 03:47 |
| mwhudson | yes | 03:49 |
| marnanel | oh, good-- thank you. are they supplied with bzr, or do I have to install them specially? | 04:03 |
| jamesh | marnanel: the public API is provided by the bzrlib Python package, which the bzr command line executable is built on top of | 04:04 |
| jamesh | so if you have bzr installed, you have bzrlib | 04:04 |
| marnanel | jamesh: awesome! thank you | 04:20 |
| marnanel | jamesh: I figured it was something like that, but I thought it couldn't hurt to ask | 04:21 |
| igc | Oh BundleBuggy, where art thou dear BundleBuggy? | 04:43 |
| igc | abentley: bb seems hung again :-( | 05:01 |
| abentley | igc: Just seems slow to me. | 05:04 |
| igc | abentley: ok - thanks for checking | 05:04 |
| AfC | One of the things that we've been doing to improve the perceived responsiveness of Bazaar is to improve the feedback in progress bars. | 05:26 |
| AfC | One place that I've noted that bzr still seems a bit wedged is when downloading monster larger packs. | 05:26 |
| AfC | I can tell from the system monitor that the network connection is maxed out, and looking at the file size one can see the file growing, so I knew full well it was doing something, but > 5 minutes with no change in the feedback given to the user seems a bit long. | 05:27 |
| AfC | Would it be wrong to give a wget style indication of the amount of data to be transferred and/or percent done (in bytes, rather than "0/2") ? | 05:28 |
| AfC | and is such a thing even possible? | 05:28 |
| AfC | (presumably if http:// as the transport it would be, I would have thought it would be with bzr:// too, but I'm not sure on which internals are relevant) | 05:29 |
| mwhudson | i'm sure i've seen such things talked about | 05:31 |
| AfC | mwhudson: yeah. I wasn't sure if anything specifically on that had been done during the 1.4 cycle. | 05:33 |
| mwhudson | i don't think so | 05:33 |
| AfC | if so, then I wouldn't have worried further about it, otherwise, when I start telling people about this repository I'll have to warn them in big letters not to freak out that it's taking so long with apparently no feedback. | 05:33 |
| lifeless | AfC: I believe it is specifically a defect in the smart server stream handling | 07:12 |
| lifeless | AfC: pack downloads do show a progress bar | 07:12 |
| lifeless | AfC: I'm not aware of anyone actively working on the bug, but I pretty sure there is a bug open. | 07:12 |
| AfC | lifeless: ... "pack downloads"; it did have a progress bar; it's just that "0/2" for ~ 300 seconds isn't terribly illuminating, that's all | 07:13 |
| lifeless | AfC: what url | 07:14 |
| AfC | lifeless: http://www.gnome.org/~afcowie/bzr/gtk+/trunk/ | 07:16 |
| lifeless | spiv: ^ can you tell if there is a smart server at that url ? | 07:22 |
| lifeless | spiv: (I can, but it should be easier) | 07:22 |
| AfC | lifeless: (I certainly didn't put one there, but I can ask Olav if necessary; I don't think he did anything fancy) | 07:23 |
| AfC | (and, netstat on that server doesn't report anything on 4155) | 07:24 |
| lifeless | AfC: we tunnel over http | 07:24 |
| spiv | lifeless: judging from -Dhpss logging, no. | 07:25 |
| AfC | lifeless: only if someone has configured mod_python etc to do so, right? | 07:25 |
| spiv | Or mod_wsgi or whatever, yeah. | 07:25 |
| lifeless | spiv: 'it should be easier' :P | 07:25 |
| AfC | spiv: yeah | 07:25 |
| spiv | lifeless: agreed. :) | 07:25 |
| AfC | lifeless: anyway, there's no getting around the fact that that pack is ~180 MB (at least, not until shallow branches); I'm just angling at the first impression factor, that's all. | 07:26 |
| lifeless | AfC: oh yeah | 07:27 |
| lifeless | AfC: I think I know the problem; | 07:27 |
| spiv | Huh, I just got a bzr: ERROR: Pack '346df6b9e93adebf6a24a2231b3eda8d' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x87b96cc> when pushing | 07:27 |
| spiv | With current bzr.dev -- which apparently has the "Avoid pack name collisions when fetching all revisions" fix. | 07:28 |
| lifeless | AfC: vila has the details, but I'm pretty sure there is a issue where http doesn't stream data to python | 07:28 |
| lifeless | spiv: that fix is not needed for push/pull code paths; only for library api user. | 07:28 |
| lifeless | AfC: so you end up with the 180 MB downloading between two lines of python code | 07:29 |
| AfC | lifeless: yippee! | 07:29 |
| AfC | That calls for a chocolate biscuit. | 07:30 |
| vila | lifeless, AfC: I''ll have to check, but from memory, if you're using pycurl you get a bit less feedback (which, I realize, in your context, could mean *far* less feedback ;-) | 07:30 |
| AfC | lifeless: one thing I was going to ask you about | suggest was that it's pretty common for people to deliberately or accidentally interrupt such a large transfer | 07:30 |
| AfC | vila: I'm using... um, you mean, one isn't supposed to "use" curl? | 07:31 |
| vila | and anyway, poolie filled a bug about using a progress bar at transport level and fixing *that* should give better feedback (with the some caveat for pycurl) | 07:31 |
| vila | AfC: We have two http implementations: one based on pycurl, the other based on the python urllib2 module | 07:32 |
| vila | pycurl is the default if installed | 07:32 |
| AfC | lifeless: so while ordinarily reducing round trips, etc is a goal we strive for, resumeability & robustness are also important | 07:32 |
| lifeless | AfC: well, its robust today while not being resumable | 07:33 |
| AfC | lifeless: maybe an upper limit on pack size would be a good idea, ie, if I had to do 180 1 MB transfers, and am interrupted half way thought, resuming from there is a bit more palatable than re-transferring 100MB | 07:33 |
| AfC | (or, of course, resuing partial downloads) | 07:34 |
| lifeless | AfC: the size of source pack doesn't influce resumability | 07:34 |
| AfC | / "continuing" / whaver | 07:34 |
| lifeless | AfC: its all about data insertion | 07:34 |
| lifeless | a single insertion is atomic | 07:34 |
| AfC | well, right now it's about downloading a 180MB file | 07:34 |
| lifeless | a single insertion must meet topological ordering across the entire set being downloaded | 07:34 |
| vila | poolie: ping, can *you* access to lp bug #183705 ? | 07:35 |
| ubotu | Bug 183705 on http://launchpad.net/bugs/183705 is private | 07:35 |
| AfC | (and all the usual patterns of download management that go with it, yeay `wget -c`) | 07:36 |
| vila | poolie: and tell me if there is something I can do about it ? | 07:36 |
| AfC | vila: ah, ok, so using pycurl is the preference. Good, that's the way things land here. | 07:37 |
| vila | AfC: hehe, *my* preference is to use urllib2 :) But that doesn't verify ssl certificates otherwise that will be the default :) | 07:38 |
| AfC | vila: [ah, I was wondering what the difference was] | 07:38 |
| lifeless | vila: fixed | 07:39 |
| lifeless | AfC: uhm, packs are not downloaded as a binary blob, desired hunks from it are grabbed with a readv | 07:40 |
| vila | lifeless: thanks, I'd be interested in the explanation of why I couldn't access it and why I could *now* access it though :) | 07:43 |
| lifeless | AfC: I appreciate the point that resuming is nice; but its simply not up there compared to the current performance issues we have. | 07:44 |
| lifeless | AfC: and as its not dealing with static content, wget -c and other download managers like torrents are not good examples to draw from | 07:44 |
| AfC | lifeless: interesting | 07:44 |
| AfC | lifeless: so, speculating, if you know you need the entire content of pack, wouldn't it be cheaper to just fire off a thread and bring that back in, lock stock and barrel? | 07:45 |
| AfC | but other than that, very interesting indeed. | 07:46 |
| lifeless | AfC: we don't know if we need the entire content of a given pack a priori - ever | 07:46 |
| AfC | really? | 07:46 |
| AfC | weird. | 07:46 |
| lifeless | we have to read the inventories from a revision X to know the text keys we want | 07:46 |
| lifeless | not weird; its a DAG of data | 07:46 |
| AfC | lifeless: yeah yeah, but I thought you had an index of inventory to which pack contained the text you needed | 07:47 |
| AfC | and vice versa | 07:47 |
| lifeless | we have indices for accessing named data keys | 07:47 |
| AfC | (the reverse indicating "yes, we need all of it") | 07:47 |
| lifeless | and the file and revision graphs are cached in the index | 07:48 |
| ubotu | New bug: #183705 in bzr "authentication.conf doesnt provide sftp login password" [Undecided,New] https://launchpad.net/bugs/183705 | 07:50 |
| lifeless | vila: it was embargoed | 07:51 |
| lifeless | vila: so that only subscribers could look at it, and had only the security contact and filer as subscribers able to access it | 07:51 |
| lifeless | AfC: over the smart protocol we can order data so that we can perform multiple small insertions if we want to | 07:54 |
| vila | lifeless: So I'd say there is a workflow bug there since no-one answered it for 4 months :-/ I better understand codeslinger angryness (I'd call that mitigating circumstance :) | 07:54 |
| lifeless | AfC: but over http doing that will give us many roundtrips | 07:55 |
| lifeless | AfC: (more than just whatever fraction of 180MB we decide to split the download size into) | 07:55 |
| lifeless | because of the need to maintain the local consistency at any insertion point | 07:56 |
| jamesh | vila/lifeless: perhaps the security team should be a team, so that such bugs can be looked at by more than just poolie (the bzr security contact) | 08:06 |
| jamesh | you'd want a restricted or moderated team, of course | 08:06 |
| lifeless | makes sense to me | 08:09 |
| lifeless | I'd use the bzr team myself | 08:09 |
| jamesh | for real security vulnerabilities, does it make sense to expose them to that many people by default? | 08:09 |
| jamesh | you can always expand the subscriber list of a bug, but it is harder to put secrets back in the box | 08:10 |
| lifeless | jamesh: I have a simple view on trust. | 08:13 |
| jamesh | lifeless: it isn't just you that matters though. | 08:15 |
| jamesh | If I find a serious security bug in Bazaar, I might be a bit hesitant to use Launchpad and disclose it to that many people. | 08:16 |
| lifeless | jamesh: well, make it a private team with hidden membership | 08:18 |
| lifeless | jamesh: then you can't tell | 08:18 |
| jamesh | except that we don't allow that ... | 08:18 |
| lifeless | jamesh: just saying | 08:18 |
| lifeless | bah | 08:25 |
| lifeless | bzr: ERROR: Connection error: Couldn't resolve host 'bazaar-vcs.org' (-2, 'Name or service not known') | 08:25 |
| lifeless | transient error | 08:25 |
| lifeless | nothing else barfs on it :( | 08:25 |
| lifeless | night all | 08:34 |
| mr-rus1 | Hi, I'm attempting to convert an svn repository with multiple branches to bazaar. and I have a few questions. | 08:44 |
| === mr-rus1 is now known as mr-russ | ||
| mr-russ | does each branch become a separate bzr branch? | 08:44 |
| mr-russ | how to svn tags fit into bzr and the possible branches? eg branch 1.1 with tag 1.1.2 | 08:45 |
| bob2 | 1) yes | 08:49 |
| mr-russ | excellent, I'm beginning to understand this stuff. | 08:50 |
| * igc dinner | 09:20 | |
| jamesh | mr-russ: I recently did a conversion using svn2bzr quite successfully | 09:30 |
| jamesh | mr-russ: it creates branches for trunk, stuff in branches/ and tags/ | 09:30 |
| jamesh | (with appropriate relationships when copies occur) | 09:30 |
| jamesh | I used a simple post-processing script to covert the branches in tags/ to bzr tags | 09:31 |
| Odd_Bloke | Morning. | 09:35 |
| poolie | hello | 09:37 |
| mr-russ | jamesh: where would I get a post processing script that does svn tags -> bzr tags | 09:59 |
| jamesh | mr-russ: http://people.ubuntu.com/~jamesh/add-tags.py | 10:01 |
| jamesh | mr-russ: the first argument is the branch you want to apply tags to, and the second is the directory containing the tag branches | 10:02 |
| mr-russ | I"ve tried to get a copy of svn2bzr, but I'm confused about how to get a working one. | 10:06 |
| mr-russ | I downloaded your branch, but it doesn't seem to be working. | 10:06 |
| jamesh | in what way? | 10:07 |
| mr-russ | trunk/svn2bzr file:///home/mr-russ/dev/home/svn/civian/ civian-bzr-all | 10:09 |
| mr-russ | what paste do we use? | 10:09 |
| jamesh | mr-russ: svn2bzr tags a Subversion dump file as input | 10:09 |
| mr-russ | svn2bzr [options] <dump file|svn-url> <output dir> | 10:09 |
| mr-russ | usage says svn-url | 10:09 |
| jamesh | hmm. I'd recommend using svn2bzr from lp:~niemeyer/svn2bzr/trunk | 10:10 |
| jamesh | it only works from dump files | 10:11 |
| mr-russ | how does one know which branch to choose? | 10:11 |
| jamesh | mr-russ: you need to use the --scheme option to tell it how your repo is laid out | 10:12 |
| jamesh | you probably want --scheme=trunk or --scheme=project | 10:12 |
| jamesh | the first is for use if you have a single-project repo with toplevel /trunk, /branches and /tags directories | 10:12 |
| jamesh | the second is for use if you have a multi-project repo with project1/trunk, projcect1/branches, project1/tags, project2/trunk, project2/branches, project2/tags, etc | 10:13 |
| jamesh | it will then have enough information to tell if a tree copy is creating a new branch/tag | 10:14 |
| mr-russ | jamesh: I meant when downloading bzr branches from launchpad. svn2bzr didn't have an obvious download to run the conversion. | 10:14 |
| jamesh | mr-russ: ah. niemeyer hasn't set his branch as the default one | 10:14 |
| jamesh | if he had, then it'd be marked as the development focus and you could just do "bzr branch lp:svn2bzr" | 10:14 |
| jamesh | I'll remind him to fix it :) | 10:15 |
| mr-russ | yeah, the trunk like is broken and very confusing when you link from the bazaar website. | 10:15 |
| mr-russ | thanks. it will help others I'm sure. | 10:15 |
| asabil | anyone knows if bzr-git usable ? | 10:36 |
| jelmer | asabil: not really | 10:37 |
| jelmer | asabil: it allows you to use bzr viz / bzr log on git repositories | 10:37 |
| asabil | I see | 10:37 |
| jelmer | asabil: but that's it afaik | 10:37 |
| asabil | thanks for the information | 10:38 |
| devilsadvocate | hi. does bazaar leave a lot or randomly named files in ~ ? | 11:09 |
| james_w | it shouldn't do | 11:10 |
| james_w | what names are you seeing? | 11:10 |
| devilsadvocate | hm,. i see a lot of them, which started showing up areound the time i started using bazaar. wanted to make sure they werent related | 11:10 |
| devilsadvocate | all have 6 characters, seem random, like a hash of some form | 11:11 |
| devilsadvocate | like QIu2Xk | 11:12 |
| james_w | I doubt they are from bzr, I've not seen them. | 11:12 |
| spiv | Yeah, that doesn't sound like bzr. | 11:13 |
| devilsadvocate | k, thanks | 11:13 |
| spiv | I'd guess that something is using $HOME for $TMP | 11:13 |
| james_w | lsof might tell you what owns them if they are still open. | 11:13 |
| jelmer | jml: hi! Does tribunal support subunit yet? | 11:41 |
| jml | jelmer: soon! | 11:41 |
| ubotu | New bug: #223585 in bzr "Bzr crashes with MemoryError during branch on OS X" [Undecided,New] https://launchpad.net/bugs/223585 | 11:42 |
| semslie | I've just started trying out bzr-svn and made my first commit back to the svn repository. I've noticed that a number of properties (bzr:revision-info, etc.) are set on the parent branch directory in subversion. Are these required? I'm asking because the other developers on this project might not like loads of properties being set around the place. If that is the only property that will be set then it might not be such a problem. | 11:42 |
| jelmer | semslie: yes, they're required - without them bzr wouldn't be able to do the right thing when you branch from svn | 11:45 |
| semslie | jelmer: At first I thought they were on all committed files, but it looks like they are only set on the branch directory, so it might not be such a problem | 11:46 |
| semslie | hopefully the extreme productivity boost from bzr will justify the extra info in trac :) | 11:47 |
| jelmer | there is a trac option to hide certain properties | 11:49 |
| === mrevell is now known as mrevell-lunch | ||
| asabil | devilsadvocate: using gedit ? | 11:56 |
| devilsadvocate | asabil, no. kde / kate | 11:56 |
| asabil | devilsadvocate: check the settings for kate then | 11:56 |
| asabil | you will also get backup files if you use bzr revert | 11:57 |
| ubotu | New bug: #223597 in bzr-loom ""record" is underdocumented" [Undecided,New] https://launchpad.net/bugs/223597 | 12:01 |
| semslie | jelmer: thanks. That might help | 12:09 |
| ubotu | New bug: #223601 in bzr-loom "up-thread: ERROR: Revision {('',)} not present" [Undecided,New] https://launchpad.net/bugs/223601 | 12:16 |
| Odd_Bloke | abentley: BB seems to be having issues (specifically with looking at a merge request, but the problem may be more general). | 12:52 |
| Odd_Bloke | abentley: The problem is more general (I know that now the front page has loaded :p). | 12:53 |
| === mrevell-lunch is now known as mrevell | ||
| visit0r | hi, what's the current recommended way to send commit emails? | 13:03 |
| visit0r | the server-side crontab script is buggy as hell | 13:03 |
| onno | Bazaar refuses to take a folder in "bzr add foo" it says foo is ignored... yet its not in my .bzrignore list | 13:34 |
| === mw|out is now known as mw | ||
| Odd_Bloke | onno: Using 'bzr ignored' will give you a list of files and the patterns that they match to be ignored. | 13:44 |
| onno | yeah but its not in there. I found out it is in the repo but won't put it in my project when I do bzr update | 13:45 |
| onno | I updated my system from 7.10 to 8.04 ubuntu yesterday... Could this be the cause? | 13:45 |
| Odd_Bloke | onno: Could you paste the command you're using and the output you get somewhere? | 13:46 |
| Stavros | hello | 13:46 |
| onno | bzr update | 13:46 |
| Stavros | how can i have bzr automatically replace version/revision tags in a file? | 13:46 |
| onno | project/nieuwsbrief/templatetags/ | 13:47 |
| onno | I don't got any error messages | 13:47 |
| onno | it simple not ther | 13:47 |
| onno | I just did a new checkout all seems fine now | 13:49 |
| Odd_Bloke | onno: OK, good. | 13:50 |
| Odd_Bloke | Stavros: Do you mean in the same way CVS does with things in betweens $s? | 13:51 |
| onno | still strange that I need to do this | 13:51 |
| Stavros | Odd_Bloke: hmm, probably, i'm not sure about that | 13:51 |
| Odd_Bloke | Stavros: Well, if so, it can't currently. | 13:51 |
| Stavros | hmm | 13:51 |
| Stavros | any idea why it's telling me that bzrlib doesn't match the bzr program? i'm on a mac | 13:53 |
| Stavros | does anyone know where i can see my repo code on launchpad? i can't find it :/ | 13:55 |
| Stavros | oh nm, browse code :/ | 13:56 |
| Stavros | hmm, how come pushing to launchpad doesn't ask me for a password? | 13:58 |
| spiv | Stavros: SSH keys | 13:59 |
| bimberi | Stavros: because you're using the ssh key you've specified to launchpad | 13:59 |
| Stavros | ah, i didn't know it used the keys for login, thanks | 14:00 |
| semslie | another beginner bzr-svn question: I'm wanting to start using bazaar as transparently as possible with the other developers on my project. Right now I have a mirror checkout and a local branch of that which I've worked on. My changes are ready, so I've merged back to the mirror checkout and then I want to commit that back to the svn repo. Unfortunately this means that I think I will end up with the commit messages that were part of the fix in my local b | 14:01 |
| Odd_Bloke | semslie: You got cut off after 'of the fix in my local'. | 14:04 |
| semslie | long question :) here's the rest: | 14:05 |
| semslie | "... fix in my local branch, and an extra message along the lines of 'merged changes', which isn't as transparent as I would like at the moment. Is there a way for my to just have just those commit messages involved in the fix committed?" | 14:05 |
| Odd_Bloke | semslie: Well, if you merge into the integration branch, you will only get a single commit in the mainline. | 14:07 |
| Odd_Bloke | If you only want commits related to the fix you've made, then that should really have been done in its own integration branch. | 14:08 |
| Odd_Bloke | Ack, it's own _feature_ branch. | 14:09 |
| semslie | Odd_Bloke: So is it best to leave out the 'mirror checkout' in this case altogether? | 14:11 |
| Stavros | isn't the bzr installer supposed to add a script to /usr/bin/bzr? | 14:13 |
| Odd_Bloke | semslie: Well, the mirror checkout could double as your integration branch (i.e. you merge into that from your feature branch and then commit to SVN from there). | 14:14 |
| Odd_Bloke | Stavros: Which bzr installer? | 14:14 |
| Stavros | 1.4rc2 | 14:14 |
| Stavros | the .tar one | 14:14 |
| Stavros | hmm, actually it copies it to /usr/local/bin/bzr | 14:15 |
| Stavros | which is not in my path, for some reason | 14:15 |
| Stavros | this is odd | 14:15 |
| semslie | Odd_Bloke: cool, thats what I was going for. When I commit from the integration branch will it commit any merged changes as a single subversion commit? | 14:15 |
| Stavros | nm, it works now that i restarted the shell | 14:15 |
| Odd_Bloke | semslie: Yes, Subversion only sees the mainline commits. | 14:21 |
| semslie | Odd_Bloke: that makes total sense now. Thanks! | 14:22 |
| Odd_Bloke | semslie: No worries. :) | 14:25 |
| Stavros | this is out of topic, but does anyone know how i can strip all html from a document with beautifulsoup? | 14:31 |
| jam | morning | 14:33 |
| Odd_Bloke | jam: Morning. | 14:35 |
| Kbyte | hi! | 14:41 |
| pekuja | Kbyte, are you a 1000 bytes or a 1024 bytes? | 14:42 |
| Kbyte | pekuja: I'm a 1024 bytes. :) | 14:44 |
| Kbyte | Damn, my boss want to buy ms team because bzr doesn't have a good frontend for windows. I'm so sad :( | 14:46 |
| jelmer | Kbyte: Mark Hammond is working hard on getting that fixed (tortoisebzr) | 14:47 |
| jelmer | Kbyte: Probably too late for you though | 14:47 |
| pekuja | MS Team? that can't be a better option | 14:49 |
| Kbyte | It isn't never too late :) tortoisebzr have the same features of olive-gtk? I looking for a tool that make easier to add files to repository, make commit, merge, ecc ecc... | 14:51 |
| pekuja | EclipseBzr? :-P | 14:51 |
| Odd_Bloke | Has anyone on the list seen my review of thumper's aliases stuff? I can't see it yet, and am beginning to worry that my messages aren't getting through. | 14:51 |
| pekuja | probably not if you don't use Eclipse | 14:51 |
| Kbyte | They don't use eclipse. Only visual studio. | 14:52 |
| abentley | Odd_Bloke: I see it. | 15:00 |
| * korpios thinks the rest of the world also needs to move to OSX/Linux environments ^_^ | 15:00 | |
| Odd_Bloke | abentley: Thanks. :) | 15:15 |
| ubotu | New bug: #223666 in bzr "bzr: ERROR: exceptions.MemoryError after commit" [Undecided,New] https://launchpad.net/bugs/223666 | 15:17 |
| === niemeyer_ is now known as niemeyer | ||
| epsy | hi | 15:47 |
| epsy | how does behave a central working copy? | 15:47 |
| epsy | (the working copy of a centralized repo) | 15:47 |
| epsy | can i set it so it only gets updated when i tell it to? | 15:48 |
| === pmezard_ is now known as pmezard | ||
| jelmer | Odd_Bloke: yep, I saw your reply to his email | 16:16 |
| Odd_Bloke | OK, good. | 16:17 |
| Odd_Bloke | jelmer: Thanks. :) | 16:17 |
| === mtaylor is now known as mtaylor|away | ||
| === beuno_ is now known as beuno | ||
| === abentle1 is now known as abentley | ||
| ubotu | New bug: #223720 in bzr "bzr switch prompts to decrypt ssh-key 4 times" [Undecided,New] https://launchpad.net/bugs/223720 | 17:06 |
| lamont | am I correct in understanding that bzr very strongly believes in the one-directory-per-branch model? | 17:29 |
| lamont | that is, that it's painfully difficult to impossible to have multiple branches in one directory and bzr checkout to get between them? | 17:30 |
| beuno | lamont, until we get nested branches, I think so, yes | 17:30 |
| dato | lamont: I'd say "mildly" difficult | 17:30 |
| * beuno stares at LarstiQ | 17:30 | |
| korpios | i.e., "git-style" branches | 17:31 |
| dato | lamont: I pasted a mini-howto the other day to madduck, if you want I could dig it up, or you could read on `bzr switch` | 17:31 |
| korpios | I did rather enjoy that part of git. | 17:31 |
| lamont | korpios: exactly | 17:31 |
| lamont | dato: I'll just stick with my current pain for now, instead of new and different pain | 17:32 |
| dato | lamont: well, your choice. I'm just surprised you come looking for something, and say "I don't want to try it" when pointed at it :) | 17:33 |
| dato | though maybe you have already, hm | 17:33 |
| lamont | dato: it was more that you pointed at it as "mildly difficult" and sent me to read stuff... ETOOMUCHPAIN | 17:34 |
| korpios | 'twould be nice to have a sort of init-repo that worked like that (a single WC, with "bzr switch") rather than the current style of init-repo and multiple branch-dirs | 17:34 |
| lamont | on the bright side, I'm actually creating something in a bzr repo instead of just smashing it into git. So I guess I'm embracing a certain amount of pain today already... | 17:34 |
| lamont | but then, I do need to learn bzr more, so it's a good pain | 17:34 |
| dato | lamont: k. feel free to come back when you feel adventureus again | 17:35 |
| Odd_Bloke | thumper: So I'm having difficulty finding a landline you could call me on ATM. My home phone has died, so I only have my mobile. :( | 17:37 |
| korpios | Maybe a plugin that created a shared repo without trees, but kept it all stuffed in the root .bzr, and swapped out a single working copy there. Hmm. | 17:37 |
| Odd_Bloke | I'm going to attempt to borrow an office from someone, but it may be too late for me to catch anyone who can let me in... | 17:37 |
| abentley | Odd_Bloke: "$ TZ=NZ date" | 17:40 |
| Odd_Bloke | abentley: We've arranged to talk this evening, so I'm hoping he'll read scrollback including his name. | 17:41 |
| abentley | lamont: A branch is always a directory. But you can organize your branches however you like, and switch your checkout between them. | 17:42 |
| takedown | hello, can anyone help with bzr and launchpad? | 18:30 |
| beuno | takedown, sure, what's the problem? | 18:31 |
| takedown | i try to upload some shell scripts to lp, everything seems works, revision history apply etc. but i dont see files on launchpad | 18:31 |
| beuno | takedown, what do you mean you don't see the files on LP? where are you looking? | 18:32 |
| takedown | beuno: i click browse code on my branch | 18:32 |
| beuno | takedown, link? | 18:32 |
| takedown | beuno: http://bazaar.launchpad.net/~takedownz/+junk/virtualsheriff/files | 18:33 |
| beuno | takedown, and did you add the files locally to the bzr repo (ie, bzr add) | 18:33 |
| takedown | beuno: sure | 18:34 |
| takedown | i do step by step with guide | 18:34 |
| beuno | takedown, I just branched it | 18:35 |
| beuno | and it seems like you didn't | 18:35 |
| beuno | it's empty | 18:35 |
| beuno | try running: bzr add | 18:35 |
| beuno | and: bzr commit -m'Message' | 18:35 |
| beuno | and pushing | 18:36 |
| takedown | beuno: ok, here what i do: bzr init in directory with project, then bzr add, and then commit and push to lp | 18:36 |
| beuno | takedown, that's correct | 18:36 |
| beuno | and the scripts where in the folder? | 18:36 |
| beuno | run: bzr status | 18:37 |
| takedown | beuno: in the same where i did bzr commands | 18:37 |
| beuno | and see if it says if there are any unknown files | 18:37 |
| takedown | beuno: before i try it and it says unknown files here, but now nothing | 18:38 |
| beuno | takedown, what does: bzr revno | 18:39 |
| beuno | say? | 18:39 |
| takedown | beuno: two, i just wait when it apply on lp | 18:40 |
| beuno | takedown, well, LP only has one | 18:40 |
| beuno | try pushing again | 18:40 |
| takedown | beuno: well, ip should apply immediately? | 18:41 |
| takedown | because when i first commit i wait almost 20 minutes when it apply to lp | 18:42 |
| beuno | takedown, it should be fairly fast, yes | 18:42 |
| takedown | beuno: ok do it again | 18:43 |
| takedown | beuno: alright, it works now | 18:47 |
| takedown | beuno: thank you | 18:48 |
| beuno | takedown, you're welcome :) | 18:48 |
| Vadi | Is it possible to embed some bzr commands into a C program? | 19:23 |
| epsy | [mode=dumbHack]hmm, exec("bzr"); ?[/mode] | 19:24 |
| andrea-bs | Vadi: you can use popen or the python C libs | 19:25 |
| Vadi | Which is easiest to make & cross platform? | 19:26 |
| Vadi | epsy: that's sounding interesting. Can I get output from that though? | 19:26 |
| Vadi | Like to confirm it worked or no? | 19:26 |
| epsy | never tried that :P | 19:26 |
| Odd_Bloke | You'd probably want to look into using the Python APIs from C. | 19:27 |
| andrea-bs | Vadi: popen uses pipes so it will work only with Unix, so you should use Python libs | 19:28 |
| Vadi | Yeh unfortunately 98% of the users are on windows. I'll look into this python thing then. | 19:29 |
| andrea-bs | Vadi: this doc may be useful: http://docs.python.org/api/api.html | 19:30 |
| === mw is now known as mw|gfood | ||
| Vadi | Thank you very much, was about to ask. | 19:30 |
| === mw|gfood is now known as mw|food | ||
| ubotu | New bug: #223814 in bzr "bzr push always fails the first time and succeeds the second time" [Undecided,New] https://launchpad.net/bugs/223814 | 19:46 |
| === mw|food is now known as mw | ||
| Vadi | It | 20:44 |
| Vadi | It's not possible to bzr push to a launchpad repository anonymously, is it? | 20:45 |
| Odd_Bloke | No. | 20:45 |
| Vadi | Oh, bah. | 20:45 |
| frsk | That would be interesting, though. :-) | 20:46 |
| sabdfl | hello all | 20:47 |
| sabdfl | how's 1.4 coming on? | 20:47 |
| abentley | sabdfl: Well, no one's reported any showstoppers with 1.4rc2. | 20:48 |
| Vadi | frsk: it's just my inability to get the curl ftp upload example to work that's causing the need for this, otherwise, not all that useful I support :) | 20:48 |
| Vadi | *suppose | 20:48 |
| sabdfl | abentley: looks like folks have been busy! | 20:50 |
| frsk | Vadi: Hehe, no, it would most likely be a new place for kiddies to place their stuff | 20:51 |
| abentley | sabdfl: Yeah, we've got plenty of pending merges ATM. | 20:52 |
| sabdfl | abentley: for 1.4, or 1.5? | 20:53 |
| abentley | For 1.5. AFAIK, all that's left for 1.4 is to package and release it. | 20:53 |
| thumper | Odd_Bloke: yes I read the scroll-back | 21:02 |
| thumper | Odd_Bloke: can you skype? | 21:02 |
| Odd_Bloke | thumper: I don't have a headset ATM, and realised that my landline was down (and that this would adversely affect your phoning me >.<) about 15 minutes after all the shops that sell them closed. :( | 21:04 |
| thumper | Odd_Bloke: ok, we could do IRC in about an hour if you are around | 21:05 |
| thumper | Odd_Bloke: gotta get the girls breakfast and myself coffee | 21:05 |
| Odd_Bloke | thumper: Yeah, that'll suit me fine. | 21:05 |
| thumper | ok | 21:06 |
| schierbeck | hey guys | 21:11 |
| schierbeck | any of y'all using bzr-gtk? | 21:11 |
| jelmer | hey Daniel | 21:11 |
| schierbeck | (i'm hoping yes) | 21:11 |
| schierbeck | oh, hi j-man! | 21:11 |
| schierbeck | jelmer: i'm fishing for some input on my latest iteration of the changes page. i'll never quit! | 21:12 |
| Odd_Bloke | schierbeck: I use it occasionally, when I need more than just a diff (for which I use 'cdiff | less -R'), a 'bzr status', or 'bzr commit'. | 21:13 |
| Odd_Bloke | So mostly viz. | 21:13 |
| abentley | Have you guys noticed that viz doesn't work at all on bzr.dev? | 21:15 |
| schierbeck | abentley: yeah, i saw it today | 21:15 |
| schierbeck | not sure what the issue is | 21:15 |
| abentley | I suspect it's incorrect ghost handling. | 21:16 |
| schierbeck | abentley: if you could provide some details and possible solutions in a bug report, you'd be the man of the week :) | 21:21 |
| abentley | By the time I know that much, I might as well fix the bug, too. | 21:22 |
| === mtaylor|away is now known as mtaylor | ||
| Vadi | Is it possible to get a link to a file in bzr at it's latest revision? (so if the revision changes, the link is still valid at least) | 21:25 |
| james_w | lifeless: hi | 21:29 |
| schierbeck | abentley: that'd make you the man of the month! :) | 21:36 |
| schierbeck | jelmer: i know you're not a fan of the changes page, but i'd still really love some feedback: lp:~dasch/bzr-gtk/changes-page | 21:48 |
| schierbeck | i've made it fit in with the bugs and signature pages | 21:49 |
| schierbeck | but it's still very rough | 21:49 |
| thumper | Odd_Bloke: we were going to talk PQM | 22:20 |
| thumper | Odd_Bloke: when are you looking at starting to work on this? | 22:20 |
| Odd_Bloke | thumper: Well, term doesn't finish until the 30th of June, with exams finishing a week or so earlier than that. | 22:21 |
| thumper | Odd_Bloke: so not until after that? | 22:21 |
| Odd_Bloke | Probably not in any depth, no. | 22:21 |
| thumper | Odd_Bloke: ah ok, that should be fine then | 22:22 |
| thumper | I'm guessing that all my major bits in PQM should be done by then | 22:22 |
| Odd_Bloke | What're you working on ATM? | 22:23 |
| thumper | lots of stuff | 22:23 |
| thumper | but with respect to PQM, getting it to talk to Launchpad | 22:23 |
| thumper | so Launchpad can be the queue rather than emailing PQM | 22:23 |
| Odd_Bloke | Oh, cool. | 22:24 |
| thumper | Odd_Bloke: also I heard rumours about you working on PQM accepting merge directives | 22:25 |
| thumper | Odd_Bloke: I know that abentley had done some work in this area a while ago | 22:25 |
| thumper | Odd_Bloke: but I don't know what state it is in | 22:25 |
| Odd_Bloke | ATM it's not altogether clear what I will actually work on. | 22:25 |
| Odd_Bloke | XMLRPC rather than (or in addition to) email was one thing, though that may overlap with talking-to-Launchpad? | 22:26 |
| Odd_Bloke | Certainly accepting merge directives would be something that might happen. | 22:26 |
| Odd_Bloke | http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms#head-f2678f1f3acd54a5199c577538301a91be6f7915-2 was the list of pet hates we got at the sprint. | 22:27 |
| Odd_Bloke | Reading that now, I'm reminded that removing the VCS abstraction that currently exists in there and making it a bzr-only tool (with use by other VCSes via bzr-svn/-hg/-git etc.). | 22:29 |
| Odd_Bloke | ...was going to be a focus as well. | 22:29 |
| abentley | schierbeck: http://bundlebuggy.vernstok.nl/bzr-gtk//request/%3C481641EB.4090901%40aaronbentley.com%3E | 22:33 |
| schierbeck | abentley: man of the month! i'll review it right away! | 22:39 |
| IsoSchiz | So... I've got some general questions about how bzr works in terms of handling distributed merges/patches. | 22:54 |
| IsoSchiz | I can't seem to find any good documentation on this anywhere, but if I'm just being dumb and there is some, perhaps someone could point me in the right direction? | 22:55 |
| james_w | hi IsoSchiz | 22:55 |
| james_w | can you explain what you are looking for please? | 22:56 |
| IsoSchiz | My question specifically is how does bzr handle/track merges across several distributed branches? Example: Devs A and B each take a private branch of the current 'head', and develop their own features. Dev B wants to build his feature on top of dev A's feature, so he syncs his branch to Dev A's branch (is this possible? Or does he have to actually take a patch file and apply that to his branch?) Then Dev B uploads his feature (built | 22:57 |
| IsoSchiz | And if that doesn't make sense, I can try to clarify some more. :-) | 22:58 |
| IsoSchiz | My interest really stems from the VCS we use at work, which is mostly centralised, and doesn't actually cope with this sort of thing very well at all, resulting in frequent merge conflicts and lost time. | 22:59 |
| mwhudson | IsoSchiz: your first line got cut off | 22:59 |
| beuno | IsoSchiz, if all devs branched from the same branch, then anyone can pull in changes from the others | 22:59 |
| IsoSchiz | Oh, sorry, broken down into smaller chunks: | 23:00 |
| IsoSchiz | My question specifically is how does bzr handle/track merges across several distributed branches? xample: Devs A and B each take a private branch of the current 'head', and develop their own features. | 23:00 |
| IsoSchiz | Dev B wants to build his feature on top of dev A's feature, so he syncs his branch to Dev A's branch (is this possible? Or does he have to actually take a patch file and apply that to his branch?) Then Dev B uploads his feature (built on top of A's feature) back to the 'head'. | 23:00 |
| IsoSchiz | Dev A does some more work on his feature, and then uploads. How does bzr minimise conflicts in this instance (i.e. half of A's code is already in the repository)? | 23:00 |
| mwhudson | IsoSchiz: how much do you know about revision control in the abstract sene? | 23:01 |
| NfNitLoop | yes, B can continually merge from A. | 23:01 |
| mwhudson | sense? | 23:01 |
| james_w | IsoSchiz: just to say that that is *exactly* the sort of situation distributed revision control is designed to deal with. | 23:01 |
| IsoSchiz | beuno: Right, but how does bzr deal with the potential merge conflicts when teh distributed versions (which may have cross synced) remerge? | 23:01 |
| NfNitLoop | and when A pushes changes, bzr only pushes things that have changed sine his last push. | 23:01 |
| IsoSchiz | mwhudson: Quite a bit. | 23:01 |
| NfNitLoop | IsoSchiz: it remembers all of the cros-syncs. | 23:01 |
| NfNitLoop | each revision has its own unique hash ID. | 23:02 |
| beuno | IsoSchiz, it tells you there are conflicts, and asks you to manually resolve them | 23:02 |
| NfNitLoop | so every branch knows which revisions have been merged in. | 23:02 |
| IsoSchiz | NfNitLoop: So there are per-branch versions? | 23:02 |
| NfNitLoop | what do you mean? | 23:03 |
| IsoSchiz | Well, in my example, Devs A and B can keep committing to their private branches. | 23:03 |
| NfNitLoop | Yes. | 23:03 |
| IsoSchiz | Then as A pushes his changes to B, B's repo knows that it last synced from 'A version x' | 23:03 |
| NfNitLoop | You should probably see: http://bazaar-vcs.org/Workflows | 23:04 |
| IsoSchiz | And also synced from 'head version y' | 23:04 |
| NfNitLoop | IsoSchiz: Don't think of it as version x or version y. | 23:04 |
| NfNitLoop | think of it as "I have merged in changes x y and z." | 23:04 |
| NfNitLoop | it doesn't matter which branch they came from. | 23:04 |
| IsoSchiz | hmmmm, and in what form does it remember the changes then? As a patchfile? | 23:04 |
| NfNitLoop | a bzr-specific changeset. | 23:05 |
| NfNitLoop | I don't know the details. | 23:05 |
| NfNitLoop | You don't have to. That's the nice bit. : ) | 23:05 |
| NfNitLoop | but that changeset is uniquely identifiable across all branches. | 23:05 |
| NfNitLoop | so any branch will know if it has merged in change X. | 23:06 |
| mwhudson | conceptually a revision is a snapshot of tree state | 23:06 |
| IsoSchiz | Right, ok, so in my example A makes 2 changesets (say X and Y), and B makes one (say Z). When B uploads his changeset (into which he has synced X from A), the main repo knows it has both Z and X, right? | 23:07 |
| NfNitLoop | yup. | 23:07 |
| IsoSchiz | So when A tries to upload X and Y, it knows it already has X and only merges in Y (and doesn't try to merge in X again)? | 23:07 |
| NfNitLoop | right. | 23:08 |
| hmeland_ | The Z revision will have X and Y among its ancestors. | 23:09 |
| hmeland_ | Sorry, only X. | 23:09 |
| NfNitLoop | Yeah, I think that's details beyond Iso's point... | 23:09 |
| NfNitLoop | he mostly sounds worried about whether each tree knows what's been merged in. | 23:09 |
| IsoSchiz | So when you do a peer sync, you actually sync more than just the current state, you sync at least some of the history of your branch as well? | 23:09 |
| IsoSchiz | That is very clever. :-) | 23:10 |
| NfNitLoop | IsoSchiz: Yes. If you pull or merge from a peer's branch... | 23:10 |
| NfNitLoop | you get ALL of the history. | 23:10 |
| NfNitLoop | history is kept across all branches. | 23:10 |
| NfNitLoop | which makes for neat graphs with bzr visualize and such. : 0 | 23:10 |
| NfNitLoop | :) | 23:11 |
| IsoSchiz | Does this make bzr much slower then...? :-) | 23:11 |
| hmeland_ | It depends. | 23:11 |
| IsoSchiz | (for network operations) | 23:11 |
| NfNitLoop | depends on how divergent your branches are. | 23:11 |
| NfNitLoop | So if you have to fetch lots of changesets, it can take a bit. BUT... | 23:12 |
| NfNitLoop | then they're all loally cached. | 23:12 |
| NfNitLoop | and any further merges only grab what's changed. | 23:12 |
| NfNitLoop | and then you can unplug your laptop and go develop at a coffee shop. :p | 23:13 |
| IsoSchiz | Yes, I'd personally sacrifice performance for greater merge stability. | 23:13 |
| NfNitLoop | IsoSchiz: What SCM systems do you use now? | 23:13 |
| NfNitLoop | I came to bzr after CVS & SVN... bzr makes it so easy to merge, it's easy to see why people so rarely bother with it in CVS & SVN. :p | 23:14 |
| IsoSchiz | At work we use a proprietary system based on ClearCase; and personally I've used both CVS and SVN quite a bit. | 23:14 |
| IsoSchiz | Right, the work system is actually pretty good at simple syncs/merges between branches, but falls down if you try to do anything slightly clever like I was describing above. | 23:15 |
| mwhudson | bzr _can_ get confused if you have criss-cross merges | 23:15 |
| mwhudson | though the new-ish 'lca' merge algorithm is much better at those | 23:16 |
| IsoSchiz | Is there a description of how the algorithm works anywhere? | 23:16 |
| mwhudson | for lca, i'm not sure | 23:17 |
| IsoSchiz | Well, anyway, thanks guys, this has been really interesting and useful! | 23:17 |
| mwhudson | IsoSchiz: http://revctrl.org/ThreeWayMerge is an interesting starting point | 23:17 |
| NfNitLoop | I guess I haven't had merges that complex... | 23:20 |
| * NfNitLoop reads up. | 23:20 | |
| abentley | mwhudson, IsoSchiz: LCA merge is described here: http://doc.bazaar-vcs.org/latest/developers/lca-merge.html | 23:26 |
| IsoSchiz | abentley: Thanks. :-) | 23:28 |
| igc | morning | 23:28 |
| poolie | hello all | 23:34 |
| mwhudson | hi poolfool | 23:34 |
| mwhudson | argh | 23:34 |
| mwhudson | hi poolie | 23:35 |
| poolie | ?? | 23:35 |
| abentley | lifeless: ping | 23:35 |
| poolie | mwhudson: what was that? | 23:35 |
| mwhudson | poolie: errant tab completion | 23:35 |
| jam | morning poolie | 23:35 |
| Odd_Bloke | 'Morning' all. | 23:37 |
| Odd_Bloke | Well, igc and poolie. :p | 23:37 |
| igc | hi Odd_Bloke - how's things? | 23:37 |
| poolie | oh i see | 23:38 |
| poolie | hello | 23:38 |
| Odd_Bloke | Not bad, not really doing as much revision as I should be. | 23:39 |
| Odd_Bloke | I've spent the majority of this evening learning Elvish, rather than actually doing something useful. >.< | 23:39 |
| poolfool | mwhudson: hello | 23:42 |
| NfNitLoop | Odd_Bloke: Learn Esperanto instead! :D | 23:45 |
| LeoNerd | EO is lovely | 23:45 |
| LeoNerd | Makes you realise how odd and annoying English is | 23:45 |
| * NfNitLoop akordas. ;) | 23:45 | |
| NfNitLoop | #bzr & ##esperanto are why I'm on this irc server. :p | 23:46 |
| Odd_Bloke | Esperanto is more useless than geeky... :p | 23:47 |
| NfNitLoop | Suit yourself. :) | 23:48 |
| * mbt actually wants to learn Esperanto, but hasn't had the time. | 23:48 | |
| radix | esperanto? come on, that's not nearly useless enough. Now *Lojban*. | 23:48 |
| NfNitLoop | I actually looked into Lojban. | 23:49 |
| NfNitLoop | I had a friend who was very into it and talked about it all the time... | 23:49 |
| NfNitLoop | but when asked, couldn't actually *say* anything in it. :p | 23:49 |
| radix | heh | 23:49 |
| Odd_Bloke | To be fair, all I'm learning is how to write English using the Elvish Tengwa, not a whole new language. | 23:49 |
| NfNitLoop | Odd_Bloke: aah, that's always fun. | 23:50 |
| NfNitLoop | I've done the same w/ esperanto and hiragana. :p | 23:50 |
| jam | radix: you beat me to bringing up Lojban | 23:59 |
| jam | not that I know it :) | 23:59 |
| radix | :-) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!