| === Meths_ is now known as Meths | ||
| poolie | hi spiv? | 00:34 |
|---|---|---|
| spiv | Hi poolie | 00:37 |
| poolie | hey | 00:37 |
| poolie | i was just going to check you were still ok to pilot | 00:37 |
| poolie | and to see if you wanted reviews or anything | 00:37 |
| poolie | i was going to work on launchpad flags and dkim but i could do that first if you want | 00:38 |
| spiv | The queue looks fairly short... although there are a couple of patches from me in it. | 00:39 |
| spiv | Perhaps take a look at https://code.launchpad.net/~spiv/bzr/fetch-spec-everything-not-in-other/+merge/42811 ? It's a prereq for the other two mps from me, although it is a pretty large diff. | 00:40 |
| spiv | Oh, although I see jam looked at a the previous iteration of it, so perhaps I should just ask him. | 00:41 |
| === frakturfreak_ is now known as frakturfreak | ||
| exarkun | Are there tools for looking directly at a repository's contents? | 04:48 |
| exarkun | or, which python api should I be looking at? :) | 04:50 |
| exarkun | like say I wanted to enumerate all of the leaf revision ids in a shared repository, can I do that? | 04:52 |
| spiv | exarkun: just a sec | 04:53 |
| exarkun | (I think I deleted a branch that had some stuff in it that I want, and my assumption is that I didn't completely destroy the data since it was a branch in a shared repository...) | 04:54 |
| spiv | exarkun: API-wise it's something like python -c "from bzrlib.repository import Repository; repo = Repository.open('code/testtools'); repo.lock_read(); g = repo.get_graph(); print g.heads(repo.revisions.keys())" | 04:57 |
| spiv | exarkun: but now that I see you don't really care about the API, try "bzr heads" or "bzr heads --all", from the bzrtools plugin | 04:58 |
| exarkun | Oh cool. Thankee. | 04:58 |
| exarkun | yay recovered | 05:01 |
| * spiv sighs and restarts his gnome-terminal process, which has run out of fds. Someone really needs to add that fix to maverick-updates... | 05:32 | |
| spiv | poolie: any thoughts on the UI change proposed in https://code.launchpad.net/~jelmer/bzr/diff-git/+merge/44185 ? (allow "bzr diff --git" rather than requiring "bzr diff --format=git") | 06:01 |
| vila | hi all ! | 07:24 |
| poolie | hi spiv | 07:29 |
| poolie | hi vila | 07:33 |
| vila | poolie: hey there ! | 07:33 |
| poolie | spiv, i answered | 07:38 |
| poolie | spiv: are you still here? | 07:40 |
| vila | Funny trick with the new 'bzr config' command: when I do a review locally, I generally create a branch whose parent is lp:bzr | 08:42 |
| vila | so when people update their branch I have to type again the url to get updates | 08:42 |
| poolie | right | 08:42 |
| vila | well, I had. | 08:42 |
| vila | Now I do: bzr config reviewed=lp:<review_url> | 08:42 |
| vila | and 'bzr pull -v `bzr config reviewed` | 08:43 |
| vila | or 'bzr diff --old `bzr config reviewed`' | 08:43 |
| vila | no more need to defined specific directory aliases like submit: , parent: and all, and it's supported by all bzr commands :) | 08:43 |
| poolie | hm | 08:47 |
| poolie | only on unix though | 08:47 |
| poolie | that's a nice reason to have config emit only the url | 08:47 |
| vila | yup, I'm so totally convinced now :) | 08:50 |
| poolie | :) | 08:56 |
| poolie | on windows we could do something like bzr pull config:reviewed | 08:56 |
| poolie | vila, we should probably defer b5 until during/after the sprint | 08:59 |
| poolie | do you want to hack on it there? | 08:59 |
| poolie | or switch to tarmac there? | 08:59 |
| === beaumonta is now known as abeaumont_ | ||
| vila | yeah, I think that would be the best, having everyone involved and aware of all the issues and debugging all nits | 09:00 |
| vila | yeah, definitely for 2.3b5 *and* tarmac, I'll update the release date | 09:01 |
| vila | .. and discuss how we reach 2.3.0 final | 09:02 |
| poolie | well, we'll need to schedule it with the sysadmins too | 09:03 |
| vila | yeah, but we can play with it on a scratch branch and ask the sysadmins to switch with a working setup | 09:04 |
| vila | (unless I miss something on how tarmac is supposed to work) | 09:04 |
| vila | but yeah, we can tell them we *will* switch around 2012-01-13 (I've update the 2.3b5 date on lp) | 09:05 |
| zyga | anyone here knows how to use bazaar.conf and lp-propose-merge to get an implicit push location | 09:51 |
| vila | zyga: Most of the time I do: bzr push lp:~vila/bzr/`bzr nick` | 10:06 |
| vila | zyga: the only way to go further today is to use locations.conf but it will take precedence over anything defined in branch.conf which is certainly not what you want | 10:07 |
| vila | zyga: there is a work in progress to allow path-based default values to be defined in bazaar.conf though | 10:07 |
| zyga | vila, I want to "bzr push" | 10:09 |
| zyga | vila, salgado gave me bazaar.conf that doesn't work that works for him | 10:09 |
| zyga | http://paste.ubuntu.com/544906/ | 10:09 |
| zyga | vila, could it be possible that salgado is riding bzr.dev wave? | 10:09 |
| zyga | vila, my real problem is on usability of lp-propose-merge | 10:10 |
| zyga | it takes bzr push + bzr lp-propose-merge while I just wanted to lp-propose-merge | 10:10 |
| zyga | (and push also is verbose as you explained, you need to specify the push branch which is tedious) | 10:10 |
| vila | zyga: sections defined in bazaar.conf are just ignored | 10:11 |
| zyga | hmm | 10:11 |
| vila | zyga: unless salgado has written a plugin... which I doubt | 10:11 |
| zyga | vila, that's what salgado is using, I need to check with him again | 10:11 |
| vila | zyga: may he uses locations.conf instea | 10:11 |
| zyga | hmm? should I put that in locations conf and see if it worsk? | 10:11 |
| zyga | I'm on 2.2.1 | 10:12 |
| vila | zyga: but the aim of locations.conf is to *override* branch.conf (so whatever is defined in branch.conf is ignored if a matching is found in locations.conf) | 10:12 |
| vila | zyga: it will work even for 2.0 I think (95% sure) | 10:13 |
| zyga | that's okay, I just want to stop having to type everything twice all the time | 10:13 |
| zyga | (something is happening) | 10:13 |
| zyga | yayt | 10:13 |
| zyga | it worked | 10:13 |
| zyga | bzr lp-propose-merge | 10:13 |
| zyga | no push needed :D | 10:13 |
| zyga | thanks :-) | 10:13 |
| zyga | hmm | 10:13 |
| zyga | (premature happines) | 10:13 |
| vila | zyga: you need to type it once, once it's defined in branch.conf it will be used (--remember can change it) | 10:13 |
| zyga | vila, I keep making branches | 10:14 |
| vila | zyga: type it once unless you define a default in locations.conf I mean | 10:14 |
| zyga | I have ~10 branches a day | 10:14 |
| zyga | http://pastebin.ubuntu.com/545877/ | 10:14 |
| zyga | what does that message mean? | 10:14 |
| zyga | this is my locations.conf | 10:15 |
| zyga | http://pastebin.ubuntu.com/545878/ | 10:15 |
| vila | hmm, it may come either from launch-control not being a project defined on launchpad or some weirdness in the stacked-on branches defined on lp (and dev focus too) | 10:15 |
| zyga | hmm | 10:16 |
| zyga | launchpad.net/launch-control exists | 10:16 |
| vila | ok | 10:16 |
| mok0 | Does anyone here have experience maintaining a gnu autotools dependent project in bzr? | 10:16 |
| vila | may be a missing trailing '/' ? | 10:16 |
| zyga | let's see | 10:17 |
| vila | zyga: if you use bzr trunk, 'bzr config' will display the expanded values that apply in the current dir | 10:17 |
| zyga | vila, I don't use trunk, sorry :/ | 10:17 |
| vila | np np | 10:17 |
| zyga | vila, is there any difference between lp:~something and the bzr+ssh://longish version? | 10:18 |
| mok0 | I'd like to know what your opinion on the autogenerated files is: do you store them in the repo? | 10:18 |
| zyga | can I just use the lp: shorthand? | 10:18 |
| vila | mok0: strictly speaking versioning generated files is... akward, but it may help when creating tarballs, but generally you don't mix the too, you version only files that a re modified by humans | 10:19 |
| vila | zyga: yes you can | 10:19 |
| zyga | I hacked the locations conf a bit and bzr info in the branch I'm working on now says: http://pastebin.ubuntu.com/545881/ | 10:19 |
| zyga | it looks good IMHO | 10:19 |
| zyga | btw, what is submit branch? | 10:19 |
| mok0 | vila: that's exactly the problem I have: "make dist" seems to work at cross purposes of bzr | 10:19 |
| zyga | I never figured that part out | 10:19 |
| vila | zyga: the difference is that the lp: shorcuts can be expanded into their http: variant under some circumstances | 10:20 |
| zyga | vila, yeah I know, if lp-login is not used | 10:20 |
| vila | zyga: submit_branch is the branch your merge from or against, a bit confusing | 10:20 |
| vila | mok0: only if you version generated files | 10:21 |
| zyga | "merge from" ? | 10:21 |
| zyga | vila, can you give me an example of what command uses that submit_branch? | 10:21 |
| vila | zyga: when you work on a feature branch and you want to update from trunk (merge new changes) | 10:21 |
| vila | zyga: merge | 10:21 |
| vila | zyga: send | 10:21 |
| vila | zyga: lp-propose :) | 10:22 |
| zyga | hmm | 10:22 |
| mok0 | vila: well, I don't like to store configure, aclocal.m4 and friends, but that means I need to generate configure, and that fails unless you have all the dependencies installed. | 10:22 |
| vila | mok0: exactly | 10:22 |
| zyga | vila, so bzr push worked for me | 10:22 |
| mok0 | Which is aPITA | 10:22 |
| vila | zyga: don't forget the :policy=append_path bit | 10:22 |
| zyga | vila, but lp-propose-merge again said that "bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/launch-control/ is not registered on Launchpad" | 10:22 |
| mok0 | OTOH, storing configure and friends in the repo is a PITA because they keep changing and it pollutes your history | 10:23 |
| vila | mok0: it's more a work flow issue than a VCS issue per se, but depending on the project they often overlap | 10:23 |
| mok0 | vila: yeah... I was just wandering if anyone had a smart solution | 10:23 |
| vila | mok0: the question is how you distribute your sources and how you want people to contribute to the project | 10:23 |
| mok0 | vila: I'm not upstream, only trying to maintain a deb package | 10:24 |
| mok0 | vila: and I _need_ to patch configure.ac | 10:24 |
| vila | mok0: either you version only non-generated files and requires devs to have the generating tools installed or you version the generated files but should ensure you're in sync at commit time | 10:24 |
| vila | oh, packaging... that's different :) | 10:24 |
| vila | mok0: In this case you have the additional issue that upstream may be versioning generated files | 10:25 |
| mok0 | vila: yes, because you do build work etc. in the directory | 10:25 |
| zyga | vila, okay, one step closer, I removed merge_target and submit_branch from locations.conf, now lp-propose-merge wants to have a reviewer, can I make it use the default reviewer for lp:launch-control somehow? | 10:25 |
| vila | zyga: search for the stacked-on branch and check that the dev focus is correct too | 10:25 |
| vila | zyga: isn't it the default ??? | 10:26 |
| zyga | hmm | 10:26 |
| vila | zyga: -R reviewer ? | 10:26 |
| zyga | vila, I don't understand either part | 10:26 |
| vila | zyga: (from 'bzr help lp-propose' I rarely use this command myself) | 10:27 |
| zyga | vila, I could use that but lp already knows who is the reviewer | 10:27 |
| vila | zyga: EPARSE | 10:27 |
| zyga | so I want to avoid having to type that, It must be a configuration issue somewhere | 10:27 |
| zyga | note: https://code.launchpad.net/~linaro-infrastructure/launch-control/trunk this is the branch I want to submit to this is the development target | 10:27 |
| vila | zyga: yeah probably | 10:27 |
| zyga | vila, if I do lp-propose-merge lp:launch-control | 10:28 |
| zyga | it says: $ bzr lp-propose-merge lp:launch-control | 10:28 |
| zyga | bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/launch-control/ is not registered on Launchpad | 10:28 |
| zyga | did I make a typo I cannot see or is there something wrong here? | 10:28 |
| vila | zyga: weird, I can 'bzr info' it but not 'bzr config' it :-/ | 10:29 |
| zyga | vila, hmm? | 10:29 |
| zyga | bzr bug somewhere? | 10:31 |
| vila | zyga: for bzr config, probably | 10:31 |
| zyga | vila, how about lp-propose-merge, why does it say that launch-control is not registered? | 10:31 |
| zyga | do I need to spell out the actual location of the branch: lp:~linaro-infrastructure/launch-control/trunk | 10:32 |
| vila | zyga: you could try that yes | 10:32 |
| zyga | that worked but said that no reviewer is specified | 10:33 |
| zyga | sigh | 10:33 |
| zyga | how did salgado make this work without passing all those arguments | 10:33 |
| vila | sounds like a launchpad config issue then | 10:33 |
| vila | zyga: check with salgado, either he has a different config or you're not part of the same teams ? | 10:34 |
| zyga | is the maintainer the default reviwer? | 10:34 |
| zyga | we are both part of the ~linaro-infrastructure team | 10:34 |
| vila | but who review the proposals ? | 10:34 |
| zyga | that team | 10:34 |
| vila | is it properly configured on lp ? | 10:34 |
| vila | 'it' being vague :) | 10:34 |
| zyga | vila, good question, how can I check that | 10:35 |
| zyga | https://launchpad.net/launch-control | 10:35 |
| zyga | maitainer is set | 10:35 |
| vila | but not driver ? | 10:35 |
| zyga | no, driver is not set | 10:35 |
| * zyga never understood what that really meant | 10:35 | |
| * vila neither :) | 10:35 | |
| zyga | I set the driver too | 10:36 |
| zyga | let's see if lp-propose-merge will work now | 10:36 |
| zyga | nope | 10:36 |
| zyga | I just want this whole review thing to get out of my way ;-) | 10:37 |
| vila | zyga: hmm, I think that's something that should be specified on the target branch or something | 10:37 |
| zyga | vila, thanks for all the help | 10:37 |
| zyga | target branch being? | 10:37 |
| zyga | trunk? | 10:37 |
| * vila looks at the bzr lp project | 10:37 | |
| vila | zyga: there is a review team for lp:bzr | 10:38 |
| zyga | bzr info does not say | 10:38 |
| vila | zyga: it's a launchpad thing | 10:38 |
| vila | zyga: look at https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev | 10:38 |
| vila | there is a review team there, but nothing comparable on launch-control (may be because I'm not part of the team there, can't say for sure) | 10:39 |
| mok0 | Is there a special channel for discussing packaging in bzr? | 10:41 |
| mok0 | Or is that here :-P | 10:41 |
| vila | mok0: here is fine | 10:41 |
| mok0 | vila, thanks | 10:41 |
| vila | mok0: #ubuntu-devel may be better if you're targeting Ubuntu (or even debian) | 10:42 |
| mok0 | So now I am wondering, should I just make all changes in the autobuild system that I need on my bzr branch | 10:42 |
| mok0 | ... and somehow create my package from that | 10:42 |
| vila | mok0: you're *creating* a package ? | 10:42 |
| mok0 | vila: ytes | 10:42 |
| mok0 | yes | 10:42 |
| mok0 | Upstream doesn't provide a recent tarball, source is distributed via svn | 10:43 |
| vila | mok0: hmm, I'll be on limited help then, I don't have a significant experience here | 10:43 |
| mok0 | I have it mirrored in an LP project | 10:43 |
| vila | good | 10:43 |
| mok0 | Then I have a branch off that called "ubuntu" :-) | 10:43 |
| vila | mok0: you're targeting Ubuntu ? | 10:43 |
| mok0 | vila: for now, yes | 10:43 |
| vila | mok0: did you look at bzr-builddeb ? | 10:44 |
| mok0 | vila: I've used it now and then, but I found it got in my way | 10:44 |
| vila | mok0: you should definitely ask in #ubuntu-devel and file bugs when it gets in your way ! | 10:44 |
| mok0 | I wasted hours until I discovered that it stashes away its own copy of the tarball in the buildarea | 10:44 |
| mok0 | I couldn't understand WFT was going on | 10:45 |
| vila | mok0: I don't know the details but there are several possible workflows, with a bit luck you're just not using the right one | 10:45 |
| mok0 | vila: perhaps yes | 10:45 |
| mok0 | vila: and then there's quilt.......... | 10:46 |
| zyga | vila, checking | 10:46 |
| vila | mok0: james_w wrote a very succint document about that, but I don't remember if/where it's published | 10:46 |
| zyga | vila, sorry, my son is ill and needed some help | 10:46 |
| vila | zyga: that's a *priority* interrupt | 10:46 |
| mok0 | vila, lemme see if mr. Google will come to my help :-) | 10:46 |
| zyga | vila, the review team _is_ set | 10:48 |
| zyga | https://code.launchpad.net/~linaro-infrastructure/launch-control/trunk/+reviewer | 10:48 |
| zyga | I can see linaro-infrastructure as the reviewer | 10:48 |
| vila | zyga: no permission to look at that | 10:48 |
| zyga | vila, right but it's set there | 10:49 |
| mok0 | vila, would you be referring to this? https://wiki.linaro.org/BzrIntroduction | 10:49 |
| zyga | I think lp might not show the reviewer if it's the same as owner | 10:49 |
| vila | zyga: :-/ I'm out of my league then | 10:49 |
| vila | mok0: no, it was one with pretty pictures :) | 10:49 |
| vila | mok0: but james_w is mentioned so you're on the right track ;) | 10:50 |
| mok0 | vila, hehe. I found this now, it looks like I need to read that: http://jameswestby.net/bzr/builddeb/user_manual/ | 10:51 |
| mok0 | No pretty pictures though | 10:52 |
| vila | mok0: certainly a must read :) | 10:52 |
| vila | mok0: may be https://wiki.ubuntu.com/UbuntuDevelopment/ is a good starting point too | 10:54 |
| mok0 | vila: Indeed... thought it mostly looks like a link-collection | 10:55 |
| vila | mok0: could be, but #ubuntu-devel can better answer than me for that | 10:55 |
| mok0 | vila: you've been most helpful, thanks | 10:56 |
| vila | mok0: np, happy to help but I know bzr better than packaging (I'm learning though ;) | 10:56 |
| mok0 | vila: I think dvcs packaging is very much in its infancy | 10:57 |
| vila | mok0: yup, actively working on though ;) | 10:57 |
| mok0 | vila: AFAIK you still need a tarball | 10:58 |
| mok0 | vila: which is kinda crazy if the source can be pulled from a branch and you can construct the debian/ from the packaging branch | 10:58 |
| vila | mok0: that's the part I'm unsure about (since I always start with a bzr branch myself) | 10:58 |
| vila | mok0: that's what 'pristine tar' is about: re-create tarballs from a branch | 10:59 |
| mok0 | vila: then that's a new definition... it used to be "the tarball you download from upstream" | 10:59 |
| mok0 | vila: anyway, I don't see there's a need for tarballs | 11:00 |
| vila | mok0: but for many operations builddeb re-creates the tarball from the branch | 11:00 |
| mok0 | vila: I know... as I wrote above, I was burned by that | 11:00 |
| vila | so instead of downloading it from upstream you just use the equivalent version | 11:00 |
| mok0 | vila: because when you edit edit edit in the branch, the old tarball is still sitting there :-( | 11:01 |
| vila | mok0: which is why I think you may not be using builddeb as intended | 11:01 |
| mok0 | vila: and so it seems your edits are gone | 11:01 |
| mok0 | vila: perhaps you are right | 11:01 |
| vila | mok0: because you seem to be doing 'normal' things, so builddeb should know how to deal with them | 11:02 |
| mok0 | vila: which is why I'd like to see a description of a proper workflow | 11:02 |
| mok0 | vila: I agree | 11:02 |
| vila | mok0: have you read the user manual you pointed above ? | 11:02 |
| mok0 | vila: not yet ... I'm not THAT fast :-) | 11:03 |
| vila | mok0: hehe, just checking, but I'm 60% sure you'll find many answers there | 11:04 |
| mok0 | vila: I am sure I kan learn a lot | 11:04 |
| mok0 | s/kan/can | 11:04 |
| === zyga is now known as zyga-coffee | ||
| === Ursinha-afk is now known as Ursinha | ||
| === zyga-coffee is now known as zyga | ||
| johnf | I'm running bzr annotate filename and I'm getting something like "bzr: ERROR: The file id "file-20060906040903-s4f1zy3gz43haztt-3" is not present in the tree" any ideas as to what the problem could be? | 13:52 |
| jelmer | hi johnf | 13:58 |
| johnf | jelmer: howdy | 13:58 |
| jelmer | johnf: I thought you were based in .au ? | 13:58 |
| jelmer | johnf: In what context? | 13:58 |
| johnf | jelmer: I usually am. In Germany for the holidays | 13:58 |
| johnf | jelmer: Let me pastie the whole thing | 13:59 |
| jelmer | johnf: Ah, nice. Enjoying the snow ? :-) | 13:59 |
| johnf | jelmer: Yes :) I've never really experienced snow before. This is totally surreal! | 14:00 |
| johnf | jelmer: sent you the pastie privately since it has some email addresses etc I'd rather not make public :) | 14:01 |
| jelmer | johnf: np | 14:01 |
| jelmer | johnf: what's the status of that file in the current working tree? | 14:02 |
| johnf | jelmer: Hmm OK maybe I'm doing something dumb | 14:03 |
| johnf | I have a branch which is currently up to rev130 and I've done this "bzr up -r 20; bzr annotate file" | 14:04 |
| johnf | that is when I get the error | 14:04 |
| johnf | if instead I do "bzr branch -r 120 orig copy; cd copy; bzr annotate file" it works fine | 14:04 |
| johnf | should the first approach work? | 14:05 |
| * jelmer wonders what "bzr up -r" does exactly | 14:05 | |
| johnf | jelmer: yeah I think that't the problem. It makes the working tree the same as rev 20. But I think when I run say the annotate command it is still working on revision 130 where the file no longer exists | 14:07 |
| jelmer | johnf: does "bzr status" report a lot of changes? | 14:22 |
| === bac` is now known as bac | ||
| jelmer | johnf: You might want to try "bzr annotate -r -1 <filename>" or "bzr annotate -r 120 <filename>" | 14:22 |
| johnf | jelmer: bzr status says "working tree is out of date, run 'bzr update'" | 14:23 |
| jelmer | johnf: ah, so "bzr up" only changes the working tree, not the branch | 14:23 |
| johnf | jelmer: yeah. Adding -r to annotate worked fine | 14:24 |
| === Ursinha is now known as Ursinha-lunch | ||
| ThiasG | Hello, thank you for making bazaar available. We switched recently from git to bazaar. | 14:32 |
| ThiasG | Now a coworker hat done a bzr rmbranch bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk | 14:32 |
| ThiasG | Is there an easy way to undo this change? | 14:32 |
| jelmer | ThiasG: hi | 14:35 |
| jelmer | ThiasG: You should be able to run "bzr heads --dead" to find the previous tip revision | 14:35 |
| jelmer | after that you should be able to create that branch again and then update it to that revision using "bzr pull -rrevid:<revid> ." | 14:37 |
| ThiasG | I found the revid. | 14:38 |
| ThiasG | The branch I just create with bzr init bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk ? | 14:39 |
| jelmer | ThiasG: yep | 14:41 |
| jelmer | ThiasG: if you don't have local access you'll need a somewhat more complicated pull command | 14:41 |
| jelmer | ThiasG: rather than using "." you should probably specify the same branch URL, once for the target (with -d) and once as source | 14:41 |
| ThiasG | I have local access to the shared repo. | 14:42 |
| ThiasG | In the trunk dir, I typed in bzr pull -rrevid:timotheus.pokorra@solidcharity.com-20101220135316-3qbh20dt0fkwi811 | 14:42 |
| jelmer | ThiasG: you'll probably need the "." after that as well, unless the default pull location has that revision | 14:43 |
| ThiasG | But this gave me "bzr: ERROR: No pull location known or specified." | 14:43 |
| ThiasG | okoay | 14:43 |
| ThiasG | Now he is working | 14:43 |
| ThiasG | All changes applied successfully. | 14:44 |
| ThiasG | Now on revision 1035. | 14:44 |
| ThiasG | I'm finished? | 14:44 |
| jelmer | should be, yeah | 14:44 |
| ThiasG | Is it correct, that I could remove the content of the trunk directory except the .bzr directory? It is the shared remote repo. | 14:45 |
| jelmer | ThiasG: yes; "bzr rmtree" should do that for you | 14:46 |
| ThiasG | I dod a bzr status, which gave me 8 modified files. | 14:47 |
| jelmer | if there are modified files you should probably check why they are modified, just in case they're changes you'd like to keep.. | 14:48 |
| ThiasG | Okay, thank you very much for your help. | 14:49 |
| ThiasG | Does someone already have a hook for restricting removing of branches? Otherwise I have to write one ;-) | 14:50 |
| jelmer | I don't think there is anything like that at the moment | 14:56 |
| ThiasG | Aber dann ist es nicht so tragisch. Ich checke sie ein, oder? | 14:58 |
| Tak | ja, selvfølgelig! | 14:58 |
| ThiasG | Sorry, wrong channel... | 14:59 |
| ThiasG | Just for completeness: The command for removing the working tree is "bzr remove-tree" | 15:05 |
| ThiasG | Thank you for your fast help :-) | 15:06 |
| === Ursinha-lunch is now known as Ursinha | ||
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| mhall119 | hi, I'm using bzrlib to do the equivilent of "bzr branch $src $dst" | 17:26 |
| mhall119 | given a remove url for $srf | 17:27 |
| mhall119 | and a local file path for $dst | 17:27 |
| mhall119 | I have: | 17:27 |
| mhall119 | src_branch.create_clone_on_transport(get_transport(destination), revision_id=rev_id) | 17:27 |
| mhall119 | but that doesn't give me a working tree in $destination | 17:27 |
| mhall119 | what am I doing wrong? | 17:27 |
| jelmer | mhall119: that's correct, branch.create_clone_on_transport() only creates a branch (and copies revisions where necessary) | 17:31 |
| jelmer | you can create a tree later by calling bzrdir.create_workingtree() | 17:32 |
| mhall119 | that did the trick, thanks a bunch | 17:46 |
| jelmer | np | 17:46 |
| === deryck[lunch] is now known as deryck | ||
| lifeless | mgz: hi | 21:15 |
| mgz | hey lifeless. | 21:31 |
| mkanat | spiv: Thanks for acknowledging and helping clarify that bug. | 23:31 |
| spiv | mkanat: you're welcome :) | 23:43 |
| mkanat | :-) | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!