| poolie | spiv, hi | 00:37 |
|---|---|---|
| poolie | approved | 00:37 |
| spiv | Thanks1 | 00:37 |
| thumper | poolie: which project was it using reviews? | 00:42 |
| poolie | stevea's project | 00:42 |
| jml | ok. so how exactly should I do this again (switching the order of a pair of adjacent threads) | 00:54 |
| thumper | a quick question about bzr send | 00:55 |
| thumper | if using `bzr send --mailto foo@example.com` and thunderbird | 00:55 |
| thumper | does the attachment get added for others? | 00:55 |
| thumper | I'm trying to debug a weirdness | 00:55 |
| poolie | how do you mean 'for others'? | 00:57 |
| * jml walks away to think about the problem. | 00:58 | |
| poolie | jml, i don't know | 00:58 |
| jml | poolie: behold, I show you a mystery | 00:59 |
| spiv | jml: edit your .bzr/branch/last-loom file? ;) | 01:09 |
| poolie | spiv, i'm reading john's pack-names patch | 01:09 |
| spiv | jml: More reasonably, pull --overwrite probably gives you the hammer you need. | 01:10 |
| jml | spiv: hmm. maybe. there are a bunch of merges that I need to work around. | 01:13 |
| jml | spiv: I'll have a play, anyway. | 01:13 |
| spiv | jml: ah, so it's more fundamentally that you need cherrypicking, rather than the ordering of the loom threads? | 01:14 |
| jml | spiv: yeah, probably. | 01:14 |
| * jml does uncommit and shelve shenanigans | 01:32 | |
| poolie | spiv, ok, i'm going to send up john's patch, what next? | 01:34 |
| jml | and look, there's a criss-cross merge. what a shock. | 01:37 |
| spiv | poolie: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081117065938.GA18818%40steerpike.home.puzzling.org%3E perhaps? | 01:38 |
| poolie | yeah | 01:39 |
| poolie | there are some nontrivial conflicts, i'm just working through them | 01:39 |
| poolie | so you're both pretty confident in that interdiffing one | 01:39 |
| spiv | Yeah. | 01:40 |
| spiv | Oh, I should land my already approved improvement item_keys_introduced_by's signatures calculation. | 01:41 |
| * spiv does that | 01:41 | |
| spiv | Not sure why I didn't notice that sooner, I guess the rapidly shrinking list of things in bundle buggy made it more obvious :) | 01:42 |
| james_w | poolie: "either 1.6 (from hardy)" <- did you mean Intrepid? | 01:42 |
| poolie | i did | 01:42 |
| === jamesh_ is now known as jamesh | ||
| spiv | poolie: I'm going to land the interdifferingserializer improvement (I'm confident and the bb:comments were essentially positive), and then I think I'm out of changes for 1.10 | 02:32 |
| poolie | ok | 02:32 |
| poolie | i've just finished resolving the pack-names thing | 02:32 |
| poolie | i'm going to send that up, then have lunch, then roll 1.10rc1 | 02:32 |
| spiv | Woo | 02:32 |
| mwhudson | poolie: getting anywhere on that bug of mine? | 02:38 |
| poolie | mwhudson: tbh not yet, we're trying to finish off work that's already queued and to get a release out | 03:03 |
| mwhudson | ok | 03:03 |
| poolie | but after that, it's top of the list | 03:03 |
| poolie | i'm not totally sure this is the right approach but things have gone for us when we try to fix just one more bug before releasing | 03:04 |
| poolie | spiv, mine merged, when yours does i'll start packaging | 03:20 |
| spiv | poolie: cool. I'm off to lunch to now. | 03:23 |
| mwhudson | huh, i managed to push https://code.edge.launchpad.net/~mwhudson/launchpad/manual-stacking-on-launchpad-branches-bug-272372 via devpad | 03:30 |
| mwhudson | which has bzr 1.9 | 03:31 |
| poolie | so are you saying your bug may be to do with the server code? | 03:31 |
| mwhudson | no | 03:32 |
| mwhudson | i pushed locally with bzr 1.9 --> boom | 03:32 |
| mwhudson | i pushed to devpad, then from devpad i seem to be able to push with bzr 1.7 | 03:32 |
| spiv | poolie: how's the releasing going? | 05:20 |
| poolie | hey | 05:24 |
| poolie | i'm uploading bzr-svn, and working out how it uses bzr builddeb | 05:24 |
| poolie | did your things all land? | 05:24 |
| spiv | Apparently so! http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n is almost unrecogniseably shorter :) | 05:25 |
| toytoy | hi guys, i was doing 'bzr uncommit' then did bzr commit, then in the other pc, i did bzr update, but I see that the last log that was part of the 'bzr uncommit' became a pendig merges. is that normal? or I want to remove that pending merges since that's no use | 05:26 |
| poolie | assuming you don't want to keep that uncommitted revision, you should revert the other checkout | 05:28 |
| spiv | toytoy: that's an interesting case. I think that is probably a bug, although not a surprising one. You can clear pending merges with "bzr revert --forget-merges". | 05:28 |
| poolie | This release of Bazaar focusses on performance improvements when pushing | 05:44 |
| poolie | and pulling revisions, both locally and to remote networks. The popular | 05:44 |
| poolie | ``shelve`` and ``unshelve`` commands, used to interactively revert and | 05:44 |
| poolie | restore work in progress, have been merged from bzrtools into the bzr | 05:44 |
| poolie | core. There are also bug fixes for portability, and for stacked branches. | 05:44 |
| poolie | how's that | 05:44 |
| spiv | Sounds good, although shelve/unshelve was rewritten rather than merely merged. | 05:46 |
| spiv | I'm not sure the distinction matters for that text, though. | 05:46 |
| poolie | to use internal merge, rather than patch and diff? | 05:46 |
| spiv | Yeah. | 05:46 |
| spiv | poolie: I'm off to SLUG. I'll have a play with the rc1 when I get home tonight :) | 06:16 |
| === poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.10rc1 released 28 Nov | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | ||
| poolie | spiv, ok, cheerio - btw (i should have reminded you earlier) i have a holiday on monday again | 06:16 |
| poolie | but john and robert will be back | 06:16 |
| spiv | poolie: I'll be on leave (OSDC that week), but pretty easy to contact. | 06:18 |
| poolie | ah, right | 06:21 |
| poolie | hm, maybe i should move it | 06:21 |
| poolie | have a fun conference anyhow | 06:21 |
| poolie | and btw it's great how many things you landed into 1.10, and that insert_r_s is coming along | 06:21 |
| vila | hi all | 07:22 |
| robin_dewd | ls | 07:44 |
| GPHemsley | Is there any way for me to merge the history of two branches that don't share a common ancestor within Bazaar, though they do share a common ancestor file-wise? | 07:57 |
| GPHemsley | fullermd: Would you happen to be around? | 07:58 |
| GPHemsley | poolie: You still around? | 08:11 |
| jamesh | GPHemsley: you can merge the two branches in a way that will give you the files from both branches | 08:18 |
| jamesh | GPHemsley: but it won't merge contents of files from the two branches | 08:19 |
| jamesh | "bzr merge -r 0.. otherbranch" should do it | 08:19 |
| GPHemsley | hmm... | 08:19 |
| jamesh | as the branches don't share history, it has no way of knowing that two files with the same name should be merged (you'll get a naming conflict), let alone how to merge the contents | 08:20 |
| GPHemsley | hmm | 08:21 |
| GPHemsley | darn | 08:23 |
| AfC | Haven't actually done it, but if you `bzr add --file-ids-from` the files into the new branch, then do the merge, it might work? | 08:29 |
| GPHemsley | It's alright | 08:30 |
| GPHemsley | it's not that important | 08:30 |
| GPHemsley | but thanks | 08:30 |
| === doko__ is now known as doko | ||
| GPHemsley | jamesh, AfC: What's the proper syntax for `bzr init-repo` via SFTP? | 08:48 |
| GPHemsley | nevermind, got it | 08:51 |
| GPHemsley | jamesh, AfC: Whats the difference between `bzr init ; bzr pull` and `bzr branch`? | 08:57 |
| maco | is it safe to install bzr 1.6 in ubuntu 8.04? | 09:00 |
| maco | im not sure if i should ask that in an ubuntu place or here | 09:00 |
| maco | i just dont know if it'd be unhappy with library versions or something | 09:00 |
| poolie | maco: yes, it's fine | 09:12 |
| GPHemsley | poolie: What is rich root? | 09:12 |
| poolie | you can get a package from launchpad.net/~bzr/+archive | 09:12 |
| maco | poolie: ok, thank you | 09:12 |
| poolie | GPHemsley: it's a series of alternate repo formats that support primarily svn interoperation | 09:12 |
| GPHemsley | Is that their only benefit? | 09:13 |
| poolie | just about | 09:13 |
| GPHemsley | ok | 09:13 |
| jamesh | GPHemsley: the only real difference between init+pull and branch is the format of the resulting branch: the first will use bzr's default format, while the second will use the format of the source branch | 09:16 |
| maco | jamesh: ooo i was wondering that | 09:33 |
| spiv | poolie: yeah, it's very satisfying watching stuff land :) | 10:49 |
| abeaumont | is it possible to set commands configuration in a configuration file or similar? e.g: i'd like to use --line switch in bzr log by default | 11:32 |
| abeaumont | configuration topic in help does't talk about such possibilities... | 11:32 |
| spiv | abeaumont: yes | 11:43 |
| spiv | abeaumont: create an alias | 11:43 |
| abeaumont | thanks spiv | 12:25 |
| abeaumont | much better than what i had in mind :D | 12:28 |
| === asac_ is now known as asac | ||
| CaMason_ | What's the best way to set up a SFTP user that will point to /srv/bzr/myrepo ? | 13:27 |
| rocky | jelmer: which version of bzr-svn should i be using for bzr-1.10rc1 ? :) | 13:33 |
| jelmer | rocky, nothing yet - 1.10 breaks API compatibility for 0.4.15 but I hope to release 0.5.0 at some point before 1.10 | 13:34 |
| rocky | jelmer: don't suppose it's safe to use a branch of bzr-svn then? | 13:35 |
| jelmer | well, it won't corrupt your repository or anything but some operations may give tracebacks | 13:35 |
| * rocky reluctantly sticks with bzr 1.9 for the time being... :) | 13:36 | |
| CaMason_ | hi guys. I've had a project under bzr control just from bzr init. Now, I've just set up a SFTP connection, and I'd like to make my current repo a central repo on the SFTP server | 13:38 |
| CaMason_ | how do I go about doing this? | 13:38 |
| jelmer | CaMason_, bzr push the branch to the sftp server | 13:41 |
| jelmer | after that, you should be able to "bzr checkout" it | 13:42 |
| CaMason_ | jelmer: thanks, I'm just reading that bit now | 13:42 |
| * rocky loves that every bzr repo can be used as-is by merely hooking up network access to it for someone else | 13:42 | |
| rocky | i don't think svn was like that right? | 13:42 |
| CaMason_ | rocky: nope | 13:43 |
| CaMason_ | you know, I think I can use a folder under both SVN and .bzr control.. | 13:43 |
| CaMason_ | i.e. my local project has a single folder that I want to put on a SVN server elsewhere (for others). If I ignore the .svn files with bzr, it shoudln't cause any conflicts, if I think correctly? | 13:44 |
| rocky | CaMason_: you can probably do something a little slicker with bzr-svn, but jelmer would be the one to poke for that ;) | 13:45 |
| CaMason_ | I think I've pushed my current repo to a central location. However, the file sizes are different | 13:52 |
| CaMason_ | the central repo seems to be about 500kb big, but my local one is about 700kb | 13:53 |
| KangOl | hi | 13:54 |
| CaMason_ | well, I managed to checkout the central branch. so.. | 13:54 |
| CaMason_ | I assume everything is ok! | 13:54 |
| beuno | CaMason_, bzr optimizes repos, so I wouldn't be surprised | 13:55 |
| KangOl | why doing a merge between 2 branches without common ancestor with cherrypicking doesn't keep the history ? | 13:57 |
| CaMason_ | and it seems I've bound my working copy to the central repo now. This is brilliant :) | 13:58 |
| CaMason_ | and I can unbind.. brillian. I can now work on the train offline :D | 14:00 |
| beuno | yes, the magic of bzr | 14:01 |
| CaMason_ | I have to say, compared to SVN, the setup process has been very painless | 14:02 |
| beuno | CaMason_, blog about it! the world needs to know! ;) | 14:03 |
| CaMason_ | I will as soon as I get my blog up | 14:03 |
| KangOl | someone can explain me this behavior ? | 14:14 |
| KangOl | ~$> bzr clone -q <urlA> A | 14:14 |
| KangOl | ~$> bzr clone -q <urlB> B | 14:14 |
| KangOl | ~$> cd A | 14:14 |
| KangOl | A$> bzr merge ../B/ | 14:14 |
| KangOl | bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 14:14 |
| KangOl | A$> bzr merge -q -r 0..-1 ../B/ | 14:14 |
| KangOl | A$> bzr st | grep pending | 14:14 |
| KangOl | pending merges: | 14:14 |
| KangOl | A$> bzr revert -q | 14:14 |
| KangOl | A$> bzr merge -q -r 0..-1 ../B/somedir/ | 14:14 |
| KangOl | A$> bzr st | grep pending | 14:14 |
| KangOl | A$> | 14:14 |
| uws | jelmer: bzr-svn seems to think subtrees of my svn checkout are are in different svn repos | 14:28 |
| uws | jelmer: refusing 'bzr commit dir1/somefile dir2/somefile' | 14:28 |
| uws | jelmer: note that this is a svn checkout, not a bzr-svn checkout | 14:28 |
| jelmer | uws, what's the exact error? | 14:50 |
| uws | ERROR: dir1/dir/somefile is not in the same branch as dir22/dir/someotherfile | 14:51 |
| uws | jelmer: ^ | 14:51 |
| uws | jelmer: "bzr root" in dir2/dir gives dir2/, instead of 2 levels up) | 14:51 |
| jelmer | uws: Ah, that's actually correct. It's fixed in 0.5, you can workaround it in 0.4 by explicitly setting a branching scheme and setting it to be mandatory | 15:01 |
| uws | jelmer: how? | 15:03 |
| uws | jelmer: what value should I use for bzr svn-branching-scheme --set svn+ssh://.... ? | 15:07 |
| uws | jelmer: repo layout is /project/{trunk,branches/tags} | 15:07 |
| uws | jelmer: my svn checkout is from /project/trunk/ | 15:07 |
| jelmer | uws, that should be trunk1 (in ~/.bazaar/subversion.conf) | 15:18 |
| rotty | hmm, I've a strange problem when using bzr+ssh: | 15:26 |
| rotty | nathot:~/src/spe/systems% bzr branch sftp://delenn/home/rotty/src/spe/systems/xitomatl | 15:26 |
| rotty | rotty@delenn's password: | 15:26 |
| rotty | bzr: ERROR: Not a branch: "/home/rotty/src/xitomatl/ | 15:26 |
| rotty | (erm, that's with sftp, but bzr+ssh yields the same error) | 15:26 |
| rotty | (note the difference between the path names specified on the command line, and in the error message) | 15:27 |
| rotty | (also, when doing the same on delenn, using 'localhost' as hostname, it works without a flaw) | 15:27 |
| rotty | arghl! bzr stores the absolute directory inside .bzr/branch/location -- so if you move the dir, this info becomes bogus. | 15:45 |
| rotty | I think storing locations globally in ~/.bazaar/locations.conf and inside ~/.bzr is a real misfeature | 15:46 |
| Odd_Bloke | rotty: What version of bzr are you using? | 15:46 |
| rotty | 1.5 | 15:46 |
| Odd_Bloke | Weird. | 15:46 |
| Odd_Bloke | I'm not seeing a ~/.bzr/branch/location... | 15:46 |
| rotty | in the repo: /path/to/repo/.bzr/branch/location | 15:47 |
| Odd_Bloke | Sorry, I didn't mean to put the ~ there. | 15:47 |
| Odd_Bloke | My fingers betrayed me. | 15:47 |
| Odd_Bloke | I'm not seeing one in my branches. | 15:47 |
| rotty | i've been bitten by stuff like that on several occassions -- no other dvcs I've used has problems when you move repos around | 15:47 |
| Odd_Bloke | rotty: Are you talking about repositories or branches? | 15:48 |
| rotty | Odd_Bloke: aren't those the same in bzr? | 15:48 |
| Odd_Bloke | rotty: No. | 15:48 |
| Odd_Bloke | A repository is Just a Bunch Of Revisions. A branch is a pointer to one of those revisions (which in turn point to their parents and so on, giving you history). | 15:49 |
| Odd_Bloke | rotty: Often, the repository and the branch will be in the same location, but not necessarily. | 15:52 |
| Odd_Bloke | For example, when using shared repositories. | 15:52 |
| rotty | I just have repos and branches that share location | 16:00 |
| rotty | (btw, removing that .bzr/branch/location file makes the branch not work anymore) | 16:02 |
| rotty | (and trying to correct it also doesn't work) | 16:04 |
| Odd_Bloke | rotty: I'm afraid I'm not sure what's going on. | 16:07 |
| Odd_Bloke | Perhaps a ML post would be in order. | 16:07 |
| rotty | well, running "bzr branch" locally, and using the newly created branch instead, worked | 16:11 |
| Odd_Bloke | rotty: Yeah, that's the recommended way of doing it. | 16:20 |
| Odd_Bloke | Sorry, it should have occurred to me to mention that. >.< | 16:21 |
| beuno | vila, going to be working on improving log performance? | 16:23 |
| beuno | you become my instant personal god if you are | 16:23 |
| vila | beuno :-) | 16:23 |
| vila | I have a problem with log, but not only a performance problem, so I'm reviewing the related bugs, tagging them along the way | 16:24 |
| vila | But out of curiosity, what is your use case (there are several ways log performance can be improved) | 16:25 |
| beuno | vila, loggerhead | 16:25 |
| beuno | so bzr log -v ;) | 16:25 |
| vila | log -v is quite a big hammer, you use it without limiting the revision range ? | 16:26 |
| beuno | vila, no, I do limit it | 16:27 |
| beuno | it's the only remaining thing we *have* to cache in loggerhead | 16:27 |
| beuno | the changed files per revision | 16:27 |
| vila | beuno: can't you use tree.iter_changes directly ? | 16:30 |
| beuno | vila, IIRC, the problem is that we have to get all the files changed for a revision in mainline, with all it's sub-revisions | 16:30 |
| beuno | for 20 (mainline) revisions at a time | 16:31 |
| beuno | on a big tree (20k revs), you think using inter_changes would be fast to get that info? | 16:31 |
| beuno | I don | 16:31 |
| beuno | I don't remember atm how we get that information | 16:31 |
| vila | beuno: oh, your context is a bit too complicated to be definitive :-/ (Except that iter_changes will only give you the delta between two arbitrary revisions and I don't think that address your "for 20 (mainline) revisions at a time" | 16:34 |
| vila | Do you need (or use) the revnos ? That can make a difference, and if you use them, you'd better *not* call log -v multiple times | 16:35 |
| beuno | vila, right, I need it per mainline revision | 16:35 |
| beuno | I only use revnos for the mainline, so it's fine | 16:36 |
| beuno | vila, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/changes | 16:36 |
| beuno | that's the page | 16:36 |
| beuno | all the information you see there is what we need to get | 16:36 |
| beuno | and, if you're interested in peaking at the file: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/247?file_id=history.py-20061211064342-102iqirsciyvgtcf-5 | 16:37 |
| beuno | vila, maybe it's _get_deltas_for_revisions_with_trees? | 16:38 |
| beuno | it says "This is copied from bzrlib.", but I suspect that comment is from the 1980's | 16:39 |
| beuno | (sept 2007, actually) | 16:39 |
| vila | beuno: right, you don't use log -v :-) You use bzrlib :) | 16:41 |
| beuno | right | 16:41 |
| beuno | but I'm hoping that improvements to one will trickle down | 16:41 |
| beuno | :) | 16:41 |
| beuno | wishful thinking? | 16:41 |
| vila | No, you're right. But my remark about revnos doesn't apply then. | 16:42 |
| vila | and changes_from calls iter_changes 2 levels down :) | 16:43 |
| beuno | right | 16:44 |
| beuno | so, "I'm screwed" | 16:44 |
| === thekorn_ is now known as thekorn | ||
| vila | beuno: nooo, just be patient ;-) | 16:45 |
| * beuno hugs vila and goes back to the launchpad bug sprint | 16:45 | |
| beuno | will I see you at UDS? | 16:45 |
| vila | beuno: no | 16:46 |
| beuno | ay... | 16:46 |
| beuno | we need a bzr sprint soon then! | 16:46 |
| Kobaz | sprinting eh | 16:48 |
| Kobaz | what do you guys use for tracking your scrums | 16:48 |
| beuno | always! | 16:48 |
| Kobaz | we use scrumworks | 16:54 |
| beuno | we use... wikis and drawings? | 16:54 |
| Kobaz | ah | 16:54 |
| Glenjamin | hey guys, i'm looking at setting up a smart server, and i'm hoping to get some sort of authenticating system where various branches can be read-only, private or public | 17:34 |
| Glenjamin | is there any existing wsgi sorta thing i can just drop in? | 17:34 |
| Glenjamin | ie: something a bit like lp, where if you push to ~user/project/branch, it knows what to do | 17:35 |
| === NfNitLoo` is now known as NfNitLoop | ||
| tristil | Does anyone use nested trees? I've had trouble getting a straight answer googling around, so I'm guessing no. | 18:25 |
| Kobaz | i like little forests | 18:28 |
| beuno | tristil, bzr doesn't support nested trees yet | 18:29 |
| beuno | LarstiQ is the mastermind behind it | 18:30 |
| beuno | but hasn't finished yet | 18:30 |
| tristil | Kobaz, I thought I liked subtrees but nested trees appears to be the best I can get. | 18:33 |
| tristil | beuno, Thanks the various references on the web and the different formats are confusing. | 18:33 |
| tristil | So people use configmanager instead for composite projects? | 18:35 |
| Kobaz | i dont even know what i want yet | 18:37 |
| Kobaz | so far i've got | 18:37 |
| Kobaz | projectcontainer/project/repo/trunk | 18:38 |
| tristil | Kobaz, but what's in projectcontainer? Is it a bzr repo/branch? | 18:42 |
| Kobaz | it's just a directory | 18:42 |
| Kobaz | like, a second order grouping of projects | 18:42 |
| Kobaz | like | 18:42 |
| Kobaz | web/mainwebsite/core/trunk | 18:42 |
| Kobaz | web/mainwebsite/modules/trunk | 18:43 |
| Kobaz | web/internal/core/trunk | 18:43 |
| tristil | Oh, well, what I really want is just svn:externals. I guess I can just keep adding, removing and exporting my subprojects. | 18:45 |
| Kobaz | aww, there's no externals in bzr? | 18:45 |
| tristil | That's what I thought nested trees were. | 18:45 |
| tristil | Of course, in Rails/Ruby they use a tool called piston to check in the externals anyway. | 18:46 |
| tristil | So you can freeze at a revision. | 18:47 |
| Kobaz | ah | 18:50 |
| === fta_ is now known as fta | ||
| === Mario_ is now known as pygi | ||
| Kobaz | dustybin: lvextend is a safe operation | 20:12 |
| Kobaz | er | 20:12 |
| === tchan1 is now known as tchan | ||
| dudus | is there a way to make nautilus integration work under ubuntu? | 20:24 |
| jelmer | dudus, the bzr-gtk ubuntu package is b0rked | 20:25 |
| jelmer | there's an open bug about it | 20:25 |
| dudus | yeah I just subscribed to it | 20:25 |
| dudus | jelmer: I think it may be solved on debian | 20:26 |
| dudus | I think It's broken since gutsy | 20:27 |
| jelmer | Yes, it is solved in Debian | 20:28 |
| jelmer | dudus, nautilus-bzr was not enabled in gutsy intentionally iirc | 20:28 |
| dudus | jelmer: why? | 20:29 |
| jelmer | dudus, it slowed down nautilus too much | 20:29 |
| dudus | ahn the good old synchronous programming | 20:30 |
| jelmer | nautilus-bzr isn't any better now, but we added a button to allow users to disable it | 20:31 |
| jelmer | the main problem is that the nautilus extension API is just too poor | 20:31 |
| dudus | jelmer: nice | 20:33 |
| LeoNerd | I'd like to split apart the files in a branch, into two branches. There's no particular logic to which goes where, other than my judgement... I could just branch it twice, then delete half the files in each side, and go on from there.. but is there a nicer way? | 21:49 |
| lifeless | LeoNerd: what you described is appropriate | 22:07 |
| LeoNerd | I've also seen 'bzr split'.. not sure about that | 22:11 |
| jelmer | LeoNerd, that splits out a specific directory, so would require you to move all of the files for one of the branches into a directory first | 22:21 |
| LeoNerd | Ahh... Hrm.. I suppose I could do that | 22:21 |
| jelmer | LeoNerd, and the result is similar to what you described | 22:21 |
| LeoNerd | Ohright | 22:22 |
| LeoNerd | OK.. So.. I've now created my two new branches on my server, each with their respective halves of the files... How to "close" the original branch, disallow further commits? | 22:48 |
| jelmer | chmod? | 22:58 |
| LeoNerd | Ooh. that'd work | 22:58 |
| lifeless | LeoNerd: or rm | 23:39 |
| lifeless | LeoNerd: but someone can always branch from the old branch and do commits; fortunately bzr will merge happily into both new branches | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!