[00:03] Peng: you can use branches to do the same thing as looms, but it's a lot more convenient with looms. [00:03] Okay. [00:05] igc: https://bugs.edge.launchpad.net/bzr/+bug/230550 [00:05] Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Critical,Confirmed] [01:04] bbiab [03:11] * igc lunch [04:17] hey guyes [04:18] spiv: ah good, you found the bug report :) [04:22] hi lifeless [04:33] lifeless: yep :) [05:34] spiv: -> food, but happy to discuss later if you need to chat about it [05:40] * igc pick up kids - bbian [06:13] spiv: back; so how is that bug going ? [06:15] lifeless: _SmartClient._base is getting out of sync with _SmartClient._medium's URL [06:15] lifeless: so it appears that the client/medium sharing logic in RemoteBzrDir isn't quite right. [06:15] spiv: excelennt; that was my suspicion :) [08:01] lifeless: http://paste.ubuntu.com/13090/ [08:01] Note that the http benchmark spend 212 seconds waiting for a 502 Bad gateway. So subtract that. [08:02] After the substraction I can't see huge differences so I'm wondering about wether there is such a discrepancy between sftp and http. [08:03] how do I bzr ignore .svn directories? [08:03] In other words, either the kenisson (sp?) experiment was flawed or I need better info on how to reproduce it. [08:03] "bzr ignore .svn" doesn't cut it? [08:04] I get errors with the bzr-svn plugin [08:04] with bzr add . [08:04] tries to do a PROPFIND [08:05] bzr add --dry-run -v . [08:05] bzr: ERROR: libsvn._core.SubversionException: ("PROPFIND request failed on '/svn/repos/keith/DocCharConvert/trunk/DocCharConvert'", 175002) [08:05] vila: you mean Kinnison? [08:06] spiv: yeah! Thanks. Thanks for your review and invalidating my bug report too ;-) [08:06] Kinnison: apologies for the typo, I need another coffee :) [08:08] vila: You're welcome :) [08:08] vila: that's the easy part compared to actually fixing a bug :) [08:09] vila: I had a quick look at it when it was reported and couldn't see what was needed, but you made the solution look pretty easy. [08:11] spiv: yeah, I had a wtf moment when realizing that _post wasn't calling _raise_curl_http_error and then another when I realized that _post wasn't using accepted_errors, that made the bug quite subtle [08:11] but overall, I'm gulty of not working more on the hpss ;-) [08:13] If _post isn't reusing stuff that it should, then it would be great to fix that :) [08:14] i'm going to do a couple of reviews of ian's work then call it a day [08:16] spiv: now that I can write tests, I may as well refactor _post, I think we shouldn't annex _post just for the smart server when we already have send_http_smart_request... [08:16] vila: that sounds good. [08:16] ... even if that means having two send_http_smart_request implementations ;-) [08:17] vila: although I'd be tempted to land a short-term fix first, before embarking on a bigger change [08:17] Depends on how quickly you can do the proper fix :) [08:19] is anyone using fish shell? (there is no tab-completion for bzr :-( [08:21] vila: is your http cached perhaps ? [08:21] vila: kinnison is usually quite good ;P [08:22] lifeless: no cache here, never, pipe is big enough (which explains why I'm so bad at undersanding squid issues and high latencies problems ;) [08:23] hmm, it looks that bash-completion is also not up to date :-/ [08:24] lifeless: I don't doubt Kinnison, it's just that I can't reproduce ;-) [08:25] Kinnison: when you come back, let's discuss a bit, I'd be interested in some stats via the transportstats plugin [08:25] I'm new to vcs, I would using it to fork my project to have 2 version: one for experimental purpose the other for production [08:27] but before this I've some questions: [08:27] 1st: I've a so called "projects" folder [08:28] is more logical to put the dir under a unique bzr branch or to create a bzr branch for each project ? [08:28] The latter. [08:30] 2nd: how can I fork my project ? should I use the switch command ? [08:32] visik7: use 'bzr branch production experimental' [08:32] well [08:32] first put your code in a directory called eg 'production' [08:32] then that will create another copy of it called experimental [08:33] and when I need to merge some or all the code from experimantal to production ? [08:35] visik7: the workflow I usually use is to develop features on their own branches [08:35] this makes it easy to merge them on their own [08:38] jamesh: so no split the code into 2 dirs ? becouse I would to continue to develop on devel and production as well [08:38] maybe I've not understand your workflow [08:39] :( [08:43] merging only part of one branch into another is a bit problematic (in bzr at the moment) === emgent is now known as emgent`UDS [08:57] vila: hi, bug me when you're around and we can discuss [09:00] night all [09:00] Kinnison: installing stuff on a windows machine in parallel, let's discuss [09:01] okies [09:01] So what are you after me for? [09:02] lifeless told me you were observing different behaviors between sftp and http regarding bandwidth usage. I can reproduce it. Can you tell me more about your experiment ? [09:02] grr, s/can reproduce/can't reproduce/ [09:03] vila: I make that typo lots too. [09:04] broadcast: read my mind while I'm using windows [09:08] vila: sure, let me prep, I've reinstalled my PC since then. [09:09] ok [09:09] Okay, so here's the deal, when I did the test, I was branching bzr.dev over my 'net connection which is a 10Mbit cable service from my Colo box which has plenty of bandwidth and reasonable enough CPU etc. [09:11] Now, this is plain http (I.E. not smart) and it seemed to take around twice (wallclock) that of sftp [09:12] I have an http_proxy set, which is on my local network to my seriously overpowered core server which runs a reasonably well configured squid [09:12] Now when it's fetching the packs, the HTTP fill the 1.2MB/s === emgent`UDS is now known as emgent [09:13] But once it's on to the smaller files, it slows down dramatically [09:14] As though it's not pipelining or something [09:14] Kinnison: (btw, I've seen the opposite effect: a bug in the way some versions of squid handle "Range: 0-..." request causing fetching of data from packs to be extremely slow) [09:14] This is an initial branch [09:15] so presumably it fetches the whole pack, no? [09:15] Depends on the pack. [09:15] oh [09:15] e.g. if it's shared repo [09:15] standalone branch [09:15] There will almost certainly be revisions in there you don't need, so bzr won't fetch the whole pack. [09:16] * Kinnison runs the branch again to re-time [09:16] bob2_: are other vcs less problematic with this kind of usage ? [09:16] since last one got moosed by presence of updatedb [09:17] Kinnison: Wait ! Can you do that with the transportstats plugin installed and prefix your urls with 'stats+' ? [09:17] where do I get that plugin? [09:17] as I did in http://paste.ubuntu.com/13090/ [09:18] bzr branch lp:~vila/bzr/transportstats [09:20] visik7: I'm not sure. jamesh was suggesting that you develop each feature in different branch, then you can choose which whole branch to merge into production or experimental [09:21] bob2_: I think that will drive me crazy 'couse I would use this as a one man developer tool [09:21] :) [09:21] vila: running the http branch now [09:23] Kinnison: You said "seemed to take around twice (wallclock)", so we may not be dealing with bandwidth problems here... [09:25] Regarding the transportstats plugin, it creates a '.transport_stats_for_bzr' file cumulating the operations measured, so let's try to be clean about how we use it, i.e. run your operations in different directories as much as possible [09:29] .. or alternatively and surely easier for you rename the file between each operation when necessary [09:29] okay, how do I get the stats for this op? [09:30] ops [09:34] night [09:38] Kinnison: bzr ts-display [09:39] visik7: it's actually nice to work on features separately [09:39] you can merge them if two features become interdependent [09:42] sabdfl: someone point me to hg queues === bob2_ is now known as bob2 [09:42] vila: http://rafb.net/p/D4vKEA23.html [09:43] vila: woah, that's huge latency [09:43] * Kinnison tries the same op again, without the http proxy [09:43] For reference, that took 4:29.06 wallclock to branch bzr.dev [09:43] visik7: i think you'll find independent branches better, it's easier to keep track of the thread of development of each feature [09:43] but, try everything [09:44] Kinnison: Beware! It's not your usual latency, that's the "real" latency as measured between when we send a request and when we receive the response, not to be confused with ping [09:44] sabdfl: and on #git they told me that "you can cherry-pick every commit you want from one branch to another" [09:44] vila: indeed, hence it seems huge [09:44] considering my average ping time is 15ms [09:44] ouch, yes, that's huge [09:45] * Kinnison tries without squid now [09:45] sabdfl: I wouldn't to start with a vcs to realize that don't do what I look for [09:45] you can try 'bzr ts-display -v' but be prepared to receive a huge output [09:47] visik7: i'm sure every tool has a way to achieve your goal [09:47] Kinnison: do you know if you use the pycurl or the urllib based implementation ? [09:47] my recommendation would be to setup a share repo, with branches in directories under that [09:47] I haven't a clue, this is a fresh hardy install, with bzr.dev [09:47] have a trunk branch, then branches for each of the features you are working on [09:47] you can merge the features into trunk when they are ready [09:47] works really well for me [09:47] try 'import pycurl', if it's there it's used [09:47] vila: right, without squid in the way, it takes 2:24 wallclock with an average latency of 420ms [09:48] sabdfl: thanks for the advice [09:48] sure [09:49] vila: not present [09:49] hmmm, squid playing tricks again :-/ Yet 420 seems still huge, let me check from here (you branched from lp:bzr ?) [09:49] No, from my server [09:49] Kinnison: good, so you're using the urllib based one [09:49] since I can monitor that and be sure it's not overloaded when I do the trials [09:49] :-) [09:49] Kinnison: apache ? [09:50] Zeus [09:50] (very high performance web server) [09:50] Kinnison: I don't know that one :-/ [09:51] SFTP is 1:53.21 wallclock with 107ms average latency [09:51] let start again then, let's forget stats, there is chances that Zeus does not handle range requests as we want, try 'bzr branch -Dhttp' and mail me the relevant .log [09:52] where does the .log end up? [09:52] sftp/ 1.53, http/2.24, that's more reasonable [09:52] bzr version will tell you, but on linux it's ~/.bzr.log [09:52] I'll clear that down first then [09:52] you can delete it before [09:52] z:) [09:52] Kinnison: perfect [09:53] branching -Dhttp now [09:53] great [09:56] I dimly remember there is a way to disable plugins for a bzr command? [09:57] uniscript: bzr --no-plugins [09:57] ta [10:00] vila: http://www.digital-scurf.org/files/http-proxied-debug.log [10:00] vila: http://www.digital-scurf.org/files/http-direct-debug.log [10:02] vila: of use? [10:02] Kinnison: just downloaded, let me look :) [10:02] for reference, that http-direct took 1:54.8 and the http proxied took 4:06.67 [10:08] the proxied one seems to choke on some very big range requests, triggering a retry that is accepted [10:09] the timings appears in the log, I need more time for a more precise analysis, I'll kept you informed [10:09] Okay, be sure to prefix with my name, I'll go off to do other things and i'll come back if this window goes red :-) [10:10] Kinnison: ok, it may not be today though, tonight at best (i.e. in ~10 hours) === pmatulis_ is now known as pmatulis [10:10] Heh, okay, I'll try and spot in scrollback [10:12] Kinnison: But one important thing already: Zeus seems to happily handle our range requests, so comparing sftp with zeus-not-proxied should be relevant in terms of relative performances *today* [10:14] sabdfl: I realized that maybe multibranch is a little bit complicated for the task that I want to acheeve: I have a project, I want to "fork" it and develop 2 different version, but only one feature is in the new branch, I would keep the 2 branch synced is it possible ? [10:14] sabdfl: sorry if I bother you [10:20] hi [10:20] statik: sorry about the plugin name thing. [10:27] jml: hello! [10:27] jml: how is europe? [10:31] mwhudson: europe is wonderful and european. [10:31] mwhudson: I wish I could spend more time here [10:32] jml: are you going to get out of the city at all? [10:33] mwhudson: unlikely. [10:33] mwhudson: it'll take a fair bit of effort to make sure I see the city, in fact. [10:34] jml: :/ [10:34] at least prague is worth seeing [10:34] mwhudson: *nod* [10:34] (i hear, not been there myself) [10:34] mwhudson: it is. [10:34] mwhudson: also, I think that the pubs here rival and perhaps best English pubs [10:34] heh [10:35] mwhudson: oh btw, I read _Rob Roy_ on the flight over. [10:35] I want to go to Scotland now. [10:35] i've seen his grave, i think [10:35] rob roy is wallace? [10:36] er, scott [10:36] yes. [10:36] poolie: hi; I may have come across badly in my latest email [10:37] poolie: please forgive :) [10:38] jml: scotland is well worth seeing [10:38] visik7: You might want http://bazaar-vcs.org/Rebase [10:38] the valley containing the church where rob roy's grave is is beautiful [10:39] jml: http://www.lochsidecottages.co.uk/Image8.jpg for example [10:42] mwhudson: yeah. indeed. [10:42] visik7: all you need to do is merge from one brancht o the other on a regular bssis [10:42] visik7: this sort of synchronisation is the reason bzr exists :) - its core functionality [10:46] visik7: bzr rebase and git-rebase and hg patch queues are all very similar... but it's better not to use them if you don't really need to. [10:58] visik7: Er, the rebase features basically help you work around certain problems... but why work around a problem when you can avoid it entirely? [10:58] ToyKeeper: how ? [10:59] If you have write access to the main branch, there is probably no need to maintain a stack of patches separate from the trunk. [11:01] But if upstream is read-only, and you have extensive local changes which upstream won't accept, 'rebase' features can help you keep your local patches up to date. [11:02] follow my reasoning: I've a project up and running, I would develop new features on a parallel brench keep syncing with the "trunk" and I need to develop new features also on trunk [11:03] so rebasing or merging seems the right solution isn't it? [11:03] In that case, regular merging should be fine. That's what bzr is best at. [11:03] so I've not understood the difference between merge and rebase [11:04] Merging is the normal process in bzr. You can push/pull/branch/merge freely. [11:05] Rebase is for pretty specific types of use. [11:05] For example, you get foo-1.3.tar.gz, unpack it, and make changes... then foo-1.4.tar.gz is released. [11:05] 'foo' is not in bzr, but your patches are. [11:06] Rebase makes it easier to take your foo-1.3 patches and make them work on foo-1.4. === AnMaster_ is now known as AnMaster [11:07] I got it [11:10] visik7: rebase writes a new history for a branch [11:10] visik7: which is detrimental to regular merging [11:14] thank you guys for all those infos, time to dive into bzr [11:14] see you soon [11:34] spiv: I see that you have a fix for bug 230550 ... does this means it goes into 1.6? [11:34] Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Critical,In progress] https://launchpad.net/bugs/230550 [11:34] brilliantnut: yes [11:36] hmm, and is there a chance that I can try it out before? [11:36] I have a branch off bzr.dev, if it makes a difference... [11:40] brilliantnut: it's a work in progress, but I just registered the branch in LP and linked it to that bug [11:40] brilliantnut: http://people.ubuntu.com/~andrew/bzr/bug-230550 is the URL === weigon_ is now known as weigon [13:01] What would cause .bzr/repository/lock/foo.tmp/info to be left behind from months ago, but not be causing problems when trying to push? [13:17] Peng: that is a tmp file used when obtaining/releasing a lock, not an actual lock [13:19] jml, no apologies needed for the plugin name, thanks for writing a useful plugin! [14:08] Hi. I have settings.py under version control but want to ignore it from now on, without removing it (it's values change from machine to machine.) How do I do that? [14:12] dennda, bzr remove --keep [14:12] bzr ignore [14:13] that's at least what I would do in such a case [14:18] thekorn: thanks :) === pmatulis_ is now known as pmatulis === wildfire` is now known as wildfire [16:21] jelmer: hi. would you please commit your latest bzr_1.5-1 upload to debian to bzr.debian.org? TIA! [16:30] siretart: are you going to upload bzr to backports? [16:36] dato: I have just merged bzrtools, and wanted to prepare an bzr upload, so yes [16:37] preparing in the sense of building and publishing it on gluck, and having it ready to be uploaded as soon as stuff transitions to testing [16:37] ah; I've been asked a backport of 1.3.1, that's why I asked [16:48] hi === weigon_ is now known as weigon [17:46] jam: ping [17:51] jam: unping, have test passing remoind me sometime to discuss write_revision_to_string with you [18:02] 1.5 has been released ? Or is it still in rc ? [18:02] lp doesn't have 1.5 series defined (hence the question) [18:02] lp doesn't have 1.6 series defined (hence the question) [18:02] grr [18:02] vila, it's been released, yes [18:03] 1.6 serie or 1.6 milestone, I'm unclear about the vocabulary, but I need the later for marking a bug as released [18:04] beuno: thks [18:05] Would I be right in thinking that 1.6 is going to be quite an exciting release? [18:05] vila: if we don't have 1.6 marked, I'll go do it [18:06] we certainly should have a milestone for it [18:06] and possibly a release series [18:06] jam: thanks [18:07] vila: we now have both a release series and a milestone for 1.6 [18:07] jam: faster than light ;-) [18:07] In the past, a lot of milestones were based on 'trunk' rather than a specific release series, but the last few have been on the series [18:07] so I kept it that way [18:08] vila: it isn't too hard when you've done it several times :) It is a bit tricky when you don't know where to look [18:08] (like that milestones aren't against the project, they are against 1 release series, etc) [18:09] man I hate that 'series' has no plural form, and that its singular form *looks* plural [18:09] stupid English [18:09] sheep [18:09] vila: is it any better in French? [18:09] is that described in the how-do-I-make-a-new-release doc ? I'm under the impression that starting the new release is always a bit ... delayed [18:10] pickscrape: sure, but at least sheep and moose don't look plural, goose geese is always bad [18:10] jam: no, in french serie is singular, series is pluaral [18:10] plural even [18:10] but we have temps (time) which is both singular and plural [18:11] and surely a few others, my gf is far better than me in french grammar, I specialized early in computer languages grammars and forget about the rest :) [18:11] vila: time as in 'occurrence' or time as in "clock" ? [18:12] time as in clock and weather and music [18:12] :) [18:13] vila: I always wondered about time as in weather, as spanish has the same thing (Tiempo) [18:13] Hace tiempo hay (or something like that) is how is the weather [18:14] Que tiempo hace ? [18:14] man my spanish is bad [18:14] jam, que tiempo hace is pretty good :) [18:16] my daughterS also suggest: nez (nose), souris (mouse), vers (rhyme) [18:16] tapis (carpet) and generally all words ending with 's' :) [18:17] gee, the things they learn at school today.... [18:18] jam: funny, time passing express both the clockl and the weather for me... [18:18] vila: sure, as an English person they seem very different, but I think most Latin languages mix them [18:20] Just that "what time is it" is very different to me than "how is the weather" [18:21] In arabic, they actually ask "Which hour is it" [18:21] vila: to your earlier question, the "mark a new series" may be in the release documents, but they are also rather long [18:21] There are quite a few steps, and it is pretty easy to miss some [18:22] I think we have to register the release in about 4+ different places (freshmeat, pypi, Bazaar home page, bazaar-announce@, etc) [18:23] Also, if it isn't there I just create one [18:23] NEWS bothers me more === NfNitLoo` is now known as NfNitLoop [18:23] because you have to wait for it to merge to mainline, and then merge it back into your simple bugfix branch [18:24] or run into merge conflicts because 2 people created the new NEWS section [18:25] yeah, we have less conflicts in NEWS since we sort it inside each section, but still... [18:27] vila: right, especially after a release when all the sections are empty [18:27] "what time is it" and "how is the weather" *are* also different in french, yet, in a movie, I often saw clouds moving faster than normal used to represent some time passing, that's the image I was referring to [18:28] jam: exactly :) Got bitten recently :) [18:28] vila: that is very common in movies, but I only view it as time sped up, you can do it with people walking fast, clock hands spinning quickly, etc [18:29] actually, I think one of the downsides is that we are slightly more likely to merge something into an "old" release [18:29] when it used to conflict all the time, you would fix it and put it in the right location [18:29] now older patches can quietly claim to fix old releases [18:30] jam: Yeah, I'm always afraid of that when working in long lived branches :-/ [18:31] and I'm quite surprised I never made a mistake there (or may be I did and nobody noticed :-( ) [18:31] vila: I *try* to be careful when I merge. And certainly for a release we should do "bzr diff -r branch:../last-release" [18:32] One thing I actually snuck in on this release were tags for '1.5rc1' and '1.5' final [18:32] though they didn't seem to propogate to bzr.dev for some reason [18:32] propagate [18:33] woo [18:33] .revisions and .signatures in use, no more _revision_store [18:33] all tests passing [18:33] jam: quirk for you [18:33] lifeless: what was your 'write_revision_string' comment? [18:33] jam: in repository.get_revision_xml [18:33] go go... go lifeless go go :) [18:34] jam: if you change it from using a stringIO to do _serializer.write_revision_to_string(), the non_ascii tests fail [18:35] lifeless: I *think* that is a bug in cElementTree.tostring versus ElementTree.write(f, 'utf-8') [18:35] lifeless: not sure, though [18:36] lifeless: you have to pass 'encoding=XXX' to tostring() [18:37] so I think you need [18:37] === modified file 'bzrlib/xml_serializer.py' [18:37] --- bzrlib/xml_serializer.py 2008-03-28 02:10:23 +0000 [18:37] +++ bzrlib/xml_serializer.py 2008-05-19 17:36:50 +0000 [18:37] @@ -87,7 +87,7 @@ [18:37] self._write_element(self._pack_revision(rev), f) [18:37] def write_revision_to_string(self, rev): [18:37] - return tostring(self._pack_revision(rev)) + '\n' [18:37] + return tostring(self._pack_revision(rev), encoding='utf-8') + '\n' [18:37] def read_revision(self, f): [18:37] return self._unpack_revision(self._read_element(f)) [18:37] lifeless: that is my guess, at least [18:39] lifeless: is get_revision_xml() used in anger anywhere? I think it used to be the basis for get_revision() but now it is defined in terms of get_revision [18:39] where can one see what do you cook for 1.6? [18:39] to, at least, smell it a bit [18:39] bzr.dev [18:41] lifeless: i did not mean to 'cook', just to smell ;) [18:42] yes,I understand [18:51] bzr tags --help suggests a --sort=ARG argument, but doesn't give a hint on what ARG can be [18:53] LeoNerd: ugh, indeed [18:53] lifeless: this is the bug with option formatting [18:53] where someone wanted a flag to always be true [18:53] but that allows "--foo" isntead of just "--sort=foo" [18:53] And the person who wrote the first patch didn't step up to fix the help formatter [18:54] so that you can get the sub-info when the setup is False [18:54] I don't remember the specific variables [18:55] the person that wrote the first patch provided an initial patch to fix the help formatter which went uncommented :P [18:56] but at this point I guess it may be time to do what somebody proposed on the list a bit ago: use value_switch=True everywhere... [18:57] dato: but that allows '--foo' which isn't what we want [18:57] bzr tags --date [18:57] rather than 'bzr tags --sort=date' [18:58] particularly, isn't what *I* wanted. I couldn't stand the idea of tags --date, so that's why I used value_switch=False, knowing the options would be undocumented... [18:59] anyway /away lunch === mw is now known as mw|food [19:22] Hello. I want to a vcs for storing versioned data in my python app. Would it be easy to import some part of bazaar and use it internally? Does bazaar require a working tree to really exist on the disk? [19:23] s/a vcs/use a vcs [19:23] TheSheep: you should be able to use the VersionedFile API [19:23] TheSheep: If you use the Knit implementation it would just create two files on disk (one for the index, one for the actual data) [19:25] jelmer: the thing is, I want to make the commits from different users in the app look like commits from different branches, without having to physically create a copy of the repository [19:29] jelmer: there is no VersionedFile api once my branch lands :P [19:29] TheSheep: yes you can do that [19:29] TheSheep: ah, ok. I misunderstood then [19:29] TheSheep: we do it ourselves in the test suite using MemoryTree's [19:30] great [19:30] thank you === rockstar_ is now known as rockstar [19:55] hmm... so memorytree.get_file will create a StringIO object, or will it actually create a file somewhere in the filesystem? === mw|food is now known as mw [20:29] if I create a project on launchpad, does that automatically create a bazaar repo that I then just have to push my initial branch to? [20:30] Pilky, you just have to push [20:30] it creates it when you push [20:30] cool, thanks === mtaylor_ is now known as mtaylor [20:38] http://kubasik.net/blog/2008/05/19/bazaar-and-its-rockage/ [20:38] :) [20:53] beuno: I think one of the biggest benefits of bazaar is that it isn't built upon the idea that there is "one true way"™ of doing things [20:53] bazaar is the mechanism, not the policy [20:53] Pilky, yes, they really got that right... [20:53] the fact that you can get all the benefits of centralised and all the benefits of distributed as and when you need them is pretty damn useful [20:55] though to be honest, having a disk image installer for OS X with a really nice background is what got me most ;) [20:55] I'm a sucker for the little things [20:55] hahah [20:56] that's the benefits of a great community :) [20:56] can one use some of launchpad features by not sharing the code? we would like to work on something before opening it to the public...you know that: "premature forking is the root of all evil " :-) [20:57] gour, well, can can *not* upload the code [20:57] I don't know how that works along the lines of policy, but it's certainly possible [20:58] ok, then we might wait a bit before using launchpad by using our own roundup tracker [20:59] gour, if it's going to be open source, I don't see a problem with it at all [21:00] hmm, ok, I think I might be a little confused by --no-trees... my branch doesn't seem to want to let me do anything [21:01] beuno: it will be, of course, open-source, most probably GPL [21:01] what exactly is the benefit of --no-trees, besides being able to put branches in branches? [21:01] gour, than I'd say go for it [21:01] Pilky: i read in the user-reference about using --no-trees and then switching checkouts around [21:01] beuno: cool. thanks [21:06] ah, I think I understand it now, --no-trees is for when you're not working on something, just when you're hosting it and don't need the extra editing related stuff === pickscrap1 is now known as pickscrape [21:12] Pilky: yes, exactly [21:12] on my laptop, i have a directory ~/foo/ which is a repository of branches of foo [21:12] so ~/foo/trunk and ~/foo/feature1 and ~/foo/feature2 [21:13] and each of those branches has all the files in it [21:13] so i can just cd into the branch, and work / hack / merge / commit [21:13] on a server, i have a repo ~/foo-storage/ [21:14] and i have setup my ~/.bazaar/locations.conf so that i can automatically push a branch to the server [21:14] just cd ~/foo/feature1; bzr push [21:14] and it automatically goes to the server ~/foo-storage/feature1 [21:14] and creates that branch on the server if it does not yet exist [21:14]