| mwhudson | jelmer: still here? | 00:39 |
|---|---|---|
| jelmer | mwhudson, somewhat | 00:44 |
| mwhudson | jelmer: python2.4, bzr 1.16.1 (1.17dev soon maybe), bzr-svn 0.6.3, subvertpy 0.6.8 | 00:45 |
| mwhudson | jelmer: all should work together ok? | 00:45 |
| jelmer | mwhudson, yes | 00:46 |
| mwhudson | jelmer: subvertpy.tests.test_properties.TestProperties.test_time_from_cstring fails, should i worry? | 00:48 |
| jelmer | not really, I think that's still the same test | 00:48 |
| mwhudson | ok | 00:48 |
| jfroy | jelmer: new bug, never seen this before: https://bugs.launchpad.net/bzr-svn/+bug/394527 | 00:55 |
| ubottu | Ubuntu bug 394527 in bzr-svn "SubversionException - "At least one property change failed"" [Undecided,New] | 00:55 |
| poolie | hello garyvdm | 01:04 |
| garyvdm | Hi poolie | 01:06 |
| lifeless | poolie: I'm off for a bit as discussed | 01:08 |
| jfroy | jelmer: I'm not sure I understand your comment on the bug. | 01:17 |
| jfroy | But does it basically mean I should make a smaller commit (a batch of commits)? | 01:17 |
| mrooney | hey bzr friends, it looks like the Limitations section of http://bazaar-vcs.org/BzrForeignBranches/Subversion is out of date (some of the limitations are addressed which is great!) | 01:30 |
| mrooney | jelmer: specifically I noticed the first and last subversion file properties, this is your domain, correct? | 01:31 |
| mwhudson | the bzr-svn tests still segfault :( | 01:46 |
| * igc back | 01:48 | |
| garyvdm | igc: I've just landed my tree widget into lp:qbzr | 02:04 |
| igc | garyvdm: excellent! I'll take a look tonight | 02:05 |
| garyvdm | and I'm busy changing qcommit, qadd, and qrevert to use it. | 02:06 |
| igc | garyvdm: cool. So that means I can add files in a directory yet to be added when that's done? | 02:07 |
| garyvdm | igc: Yes - I've got it showing the contents of a unversioned dir. | 02:07 |
| igc | garyvdm: hooray! | 02:08 |
| garyvdm | But getting it to decide how to pass the parameters to the subprocess is a bit of a challenge | 02:08 |
| garyvdm | If you change the selection in a subdir, it needs to pass the subitems and say --no-recurse. And if you don't change any thing, it must not pass the sub items, and not pass --no-recurse. | 02:10 |
| garyvdm | And if you have mix???? | 02:11 |
| garyvdm | igc ^^^ | 02:11 |
| igc | garyvdm: why is no-recurse needed when a subitem is selected? If that itself was a subdir, I'd expect it to recurse from there? | 02:12 |
| garyvdm | If you have 1 sub items that is deselected, you need to pass no-recures, and pass all the other items that remained selected. | 02:13 |
| garyvdm | igc ^^^ | 02:13 |
| igc | garyvdm: ok, I'll give it a go tonight. Thanks for getting this going | 02:14 |
| RenatoSilva | https://bugs.eclipse.org/282226 | 03:27 |
| bob2 | is there a bzr.dev-as-2a branch somewhere? | 03:33 |
| spiv | bob2: Probably only as throw-aways on a couple of devs laptops. | 03:36 |
| spiv | I don't think we want to start inviting people to make rich-root revisions that they might submit back to us until bzr.dev itself is in a rich-root format. | 03:37 |
| bob2 | ah, fair enough | 03:37 |
| poolie | jelmer: are you still here? | 03:40 |
| === timchen119 is now known as nasloc__ | ||
| * igc lunch | 03:56 | |
| poolie | spiv, hello! how's it going? | 04:50 |
| spiv | poolie: good, I have InterDifferingSerializer and streaming fetch sharing the same code for generating new roots. | 05:59 |
| spiv | I got a bit alarmed at https://bugs.edge.launchpad.net/bzr/+bug/196080/comments/1 this morning | 06:02 |
| ubottu | Ubuntu bug 196080 in bzr "`bzr info -v bzr://host/branch` hides actual branch/repo format" [Medium,Confirmed] | 06:02 |
| poolie | yeah, i saw your reply | 06:36 |
| lifeless | it would be nice if fixed bugs could not be touched except by team members | 06:36 |
| poolie | not reopened? | 06:42 |
| lifeless | not touched, even comments on fixed tasks are noise - I'd much rather the user get directed to open a new bug | 06:44 |
| poolie | cos i just reopened a fixed bug in launchpad to point out it's actually not fixed | 06:45 |
| spiv | Well, perhaps after say 3 months? | 06:45 |
| lifeless | spiv: something. | 06:45 |
| poolie | arguably i should have opened a new one but that's kind of noise too | 06:45 |
| poolie | some kind of warning would be good | 06:45 |
| lifeless | poolie: true, OTOH the lp dev could: dup it, reopen the original. | 06:45 |
| spiv | Certainly I wouldn't immediately assume it's wrong for a user to reopen a bug within a week, but for sufficiently old bugs it's almost certainly better to open a new bug. | 06:45 |
| lifeless | I have a strong bias to 'always open new bugs' | 06:46 |
| lifeless | because dupping is easy | 06:46 |
| spiv | Yeah, I flied a bug about this today. I think there should be a way to take a comment and automatically turn it into a new bug (and remove/hide the original comment). | 06:47 |
| spiv | So that splitting becomes easier, although still not as easy as marking a dupe. | 06:47 |
| spiv | Oh, interesting, read_inventory_from_string doesn't work with CHKSerializers. | 06:48 |
| spiv | Or perhaps I'm feeding the wrong thing to it. | 06:48 |
| spiv | No, I don't think I am... | 06:49 |
| lifeless | spiv: it can't | 06:50 |
| lifeless | spiv: or rather, its used in places that want to do one IO to get an inventory and so we chose to make it error, IIRC. | 06:50 |
| spiv | Hmm, well, the code we had is feeding the wrong thing, rather than my code per se ;) | 06:50 |
| stefanlsd | garyvdm: congrats on getting qbzr 0.11 into karmic :) | 06:57 |
| garyvdm | stefanlsd: Thanks for all the help. | 06:57 |
| garyvdm | stefanlsd: I guess I got to find some other packaging to do :-) | 06:58 |
| stefanlsd | garyvdm: np! yeah! lots of stuff to do! :) | 07:00 |
| lifeless | poolie: http://paste.ubuntu.com/207940/ | 07:02 |
| spiv | Ah, I see, get_stream_for_missing_keys is producing fulltext inventories... | 07:02 |
| poolie | typo introducead | 07:04 |
| vila | hi all, I'll be barfu (back after reboot for update :) | 07:05 |
| === abentley1 is now known as abentley | ||
| lifeless | gnight | 08:24 |
| johnskulski | I have shelved some changes. then i made a change and committed. now when i try to unshelve I get an error about it not merging cleanly. How can I go forward? | 08:25 |
| === RAOF_ is now known as RAOF | ||
| === ivan is now known as Guest40910 | ||
| === Guest40910 is now known as ivan | ||
| lifeless | unshelve --force ? | 08:35 |
| === visik71 is now known as visik7 | ||
| lifeless | poolie: you might enjoy http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html | 09:10 |
| vila | poolie: regarding bug #261770, it seems that both users really wanted 'bzr revert -rxxx' even if they tried 'bzr uncommit -r xxx' they both wanted to follow that by 'bzr revert' | 09:24 |
| ubottu | Launchpad bug 261770 in bzr "cannot uncommit to a non-mainline revision" [Medium,Confirmed] https://launchpad.net/bugs/261770 | 09:24 |
| vila | poolie: so what fix do you think about here ? Giving a proper error message pointing to bzr revert ? | 09:24 |
| vila | poolie: making uncommit -r accept non left-hand revisions seems wrong to me | 09:25 |
| lifeless | vila: why ? | 09:25 |
| vila | if it's not in my left-hand ancestry I didn't commit it, how come I can uncommit it ? | 09:25 |
| lifeless | someone pushed to it pivoting your history | 09:26 |
| lifeless | so you may well have committed it | 09:26 |
| lifeless | also, I don't see why not being the committer should have anything with the ability to uncommit | 09:26 |
| vila | because, to me, uncommit means: "Oh wait, that (these) commits were wrong, put me in a state where I can commit again (i.e. don't change a single bit in working tree, the state is fine, but put me in the ancestry graph at *that* point) | 09:28 |
| lifeless | sure | 09:28 |
| lifeless | I don't see why we should cripple its ability | 09:29 |
| vila | what the reporters want (in *both* cases) is: give me the working tree at that revision | 09:29 |
| * igc dinner | 09:29 | |
| lifeless | vila: well, I'd investigate why they thought uncommit would change the wt | 09:29 |
| lifeless | vila: but that seems orthogonal to me | 09:29 |
| vila | lifeless: full agreement, hence my question | 09:30 |
| lifeless | vila: let me put this another way | 09:30 |
| lifeless | vila: given that uncommit == 'bzr pull . -r <arg> --overwrite' minus the tree changes | 09:30 |
| lifeless | vila: why put additional constraints on it | 09:31 |
| lifeless | well, its really EOD for me now. | 09:32 |
| * lifeless puts the laptop away | 09:32 | |
| * vila tries the desktop | 09:32 | |
| vila | lifeless: I see, have a good eveniing | 09:32 |
| poolie | hi vila | 10:09 |
| vila | hey poolie ! | 10:10 |
| vila | jam: too early, go back to sleep ! | 11:05 |
| === vk5foss is now known as Kamping_Kaiser | ||
| jam | vila: definitely too early, just my machine losing and then gaining network access :) | 14:09 |
| vila | jam: :-D | 14:10 |
| vila | good morning jam (should be better now :-) | 14:10 |
| vila | jam: It could have been your son waking you up and you not finding your sleep anymore :-) | 14:10 |
| jam | yeah | 14:11 |
| jam | that certainly happens sometime | 14:11 |
| jam | but I usually don't have trouble finding my sleep | 14:11 |
| jam | my wife does, though | 14:11 |
| === Xhema is now known as XhemaN | ||
| === XhemaN is now known as XhemaNeShtepi | ||
| mozmck_work | is it possible/recommended to have multiple unrelated projects in one repository? | 15:33 |
| ddaa | it is possible | 15:34 |
| mozmck_work | I have numbers of personal projects I am working on, and my thought is that it would be nice to have my whole projects directory in one repository so I can do a single commit or update to save work on them all at once. | 15:35 |
| ddaa | that's something different than putting different projects in one repository | 15:35 |
| mozmck_work | ok, what would be the best way to do that? | 15:35 |
| ddaa | the short answer is: you can't | 15:36 |
| ddaa | the slightly longer is: you could look at the scmproj plugin which might do something close to what you want | 15:36 |
| ddaa | the longer is: "I'm not sure you are clear on what you want to do. Why do you want to do commits in unrelated projects at once?" | 15:37 |
| ddaa | What we call that in bzr land is "nested trees". And they are not supported yet, with no defined timeline. | 15:38 |
| ddaa | The main use case for nested trees tracking is recording which revisions of multiple interdependent projects go toghether. | 15:39 |
| ddaa | Unless you have a specific need for something like that, I would just write myself some shell scripts. | 15:39 |
| mozmck_work | ok, I have a projects directory with 10 or 20 different projects. PIC micro firmware, computer software etc. | 15:40 |
| mozmck_work | sometimes I may work on 3 or 4 or more of these in a day | 15:40 |
| mozmck_work | they are currently not in version control at all, but I want to put them there for revision history, and because I work on them on 3 or so different computers from several locations. | 15:41 |
| mozmck_work | my thought was if I could just put the whole projects directory as a repository I could commit everything under it at once. | 15:42 |
| dash | mozmck_work: are you changing everything at once? would they all hav ethe same commit message? :) | 15:42 |
| mozmck_work | hmmm, the commit message would be a problem I guess. | 15:43 |
| dash | i guess i'm not understanding why you'd want to commit to separate projects simultaneously | 15:43 |
| mozmck_work | I should probably just commit each one when I get done with it. | 15:43 |
| dash | probably :) | 15:43 |
| mozmck_work | well, to save time and having to remember which ones I even worked on! | 15:44 |
| ddaa | The recommended style in bzr is actually: commit whenever you have a "good" state, or a state you want to share. | 15:44 |
| dash | mozmck_work: that sounds weird :) | 15:45 |
| dash | why wouldn't you commit after running your tests? | 15:45 |
| mozmck_work | yeah, but I'm working alone. | 15:45 |
| ddaa | It's recommended to do multiple commits on a branch within a single session, as dash said, after runnig the tests. | 15:46 |
| mozmck_work | well, some of these are for work, and I work on them at work and at home. | 15:46 |
| dash | ok? | 15:46 |
| mozmck_work | so I use a thumb drive right now to bring stuff back and forth. | 15:46 |
| dash | sure | 15:46 |
| mozmck_work | and I forget at times which computer has the newest version of which program. | 15:47 |
| mzz | bzr can certainly be useful for that kind of sharing, but the recommended way to use it is to commit considerably more frequently than once a day when you're moving between systems | 15:47 |
| mozmck_work | that's what I'll need to do. | 15:47 |
| dash | mozmck_work: why are you waiting so long to commit? | 15:47 |
| mzz | (I do use bzr to prevent getting confused and having multiple diverging versions of the code spread across systems) | 15:48 |
| ddaa | mozmck_work: note, you will not NEED to commit more often. We say it's good practice, and doing so gives you the full benefit of the tool. | 15:48 |
| mozmck_work | I'm not yet because I don't use VCS. | 15:48 |
| mozmck_work | I need to or my code will be at work when I want it at home :) | 15:48 |
| mzz | you most definitely *can* stick multiple projects into the same branch, which would let you commit all of them. But if you do that it's relatively hard to get a single project back out. | 15:48 |
| mzz | bzr isn't like svn in that | 15:49 |
| mozmck_work | mzz: that makes sense. | 15:49 |
| mozmck_work | it was kind of a wild idea I guess :) | 15:50 |
| mzz | assuming both systems are networked I'd use one bound branch per project and a shared repository somewhere reachable from both | 15:50 |
| mzz | that just leaves figuring out how to deal with changes that aren't quite ready for a commit before you move between systems | 15:51 |
| mozmck_work | I can set up a server to network them. | 15:51 |
| mozmck_work | what is a bound branch? | 15:51 |
| mzz | if they're not networked you can put that shared repo on a thumb drive | 15:52 |
| mzz | I'm hoping bound branches are explained in the documentation, sec... | 15:52 |
| mzz | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-checkouts but that's not ideal. Can someone give me a better doc link? | 15:53 |
| mzz | or give mozmck_work a better doc link, really | 15:53 |
| mozmck_work | ok, I can find it. but only one shared repository per project right? | 15:53 |
| mzz | well, depends | 15:54 |
| mzz | afaict you won't need more than one for what you're doing | 15:54 |
| mzz | <-- not a bzr expert though | 15:54 |
| mozmck_work | me neither (obviously!) | 15:55 |
| mozmck_work | I'll keep reading. there's too many options... | 15:55 |
| igc | night all | 16:04 |
| awilkins | Wowzer, sourceforge.net got all purrrty | 16:07 |
| Xavura | impossible! | 16:07 |
| Xavura | oh wow | 16:07 |
| ddaa | why do sf.net look like twitter all of a sudden? | 16:10 |
| * awilkins registers sourcetwit.net | 16:11 | |
| Xavura | they're kinda late to hop onto the web 2.0 bandwagon but err | 16:11 |
| ddaa | Apparently, their web20 script monkeys STILL have not heard of this innovation: margins | 16:12 |
| Xavura | rofl | 16:13 |
| kfogel | bzr pack | 16:13 |
| kfogel | bzr: ERROR: Pack '39d0c482e6e64ea0f509082e76b76e37' already exists in <bzrlib.repofmt.groupcompress_repo.GCRepositoryPackCollection object at 0x8ba604c> | 16:13 |
| kfogel | anyone know what that's about? ^^ | 16:14 |
| Xavura | does look a bit croweded | 16:14 |
| ddaa | that's a bug in bzr-hg, bzr-git whatever your are trying to use. | 16:14 |
| kfogel | That was from the final command in 'bzr reconcile && bzr upgrade --2a && bzr pack' with very latest bzr bleeding-edge. | 16:14 |
| kfogel | ddaa: (were you responding to me?) | 16:14 |
| dash | also they bought Ohloh | 16:15 |
| ddaa | kfogel: yup, I guessed (apparently wrong) what you were trying to do. | 16:15 |
| kfogel | ddaa: yeah, this was just a straight upgrade to the brisbane-core format | 16:15 |
| mzz | well, http://sourceforge.net/ is currently giving me a *very* pretty 500 page | 16:15 |
| mzz | I'm not sure that's what you folks meant though | 16:15 |
| ddaa | mzz: well, no. But I guess you can still see the improvement from where you stand :) | 16:16 |
| jelmer | kfogel, Afaik that happens if you try to pack while there is nothing to pack, and you end up generating a new pack file with the same contents (and hash) | 16:16 |
| Peng_ | jelmer is correct. There could always be some other cause, of course, but it's probably that. Bug #382463. | 16:20 |
| ubottu | Launchpad bug 382463 in bzr "'bzr pack' of an already packed dev6 or 2a repo fails with Pack exists" [Medium,Triaged] https://launchpad.net/bugs/382463 | 16:20 |
| kfogel | Peng_: dang it. I just was over in the bug tracker finding that bug. I should have waited for you to say it! | 16:21 |
| Peng_ | "bzr pack" on older formats just reorganizes data, so they short-circuit when there's only 1 pack file, but BBC recompresses too, so packing when there's only one pack may still lead to a different file. | 16:23 |
| Peng_ | So it's a bit harder to decide what to do to fix it. | 16:23 |
| kfogel | Peng_: well, it could attempt to recompress and then if there's no advantage, just remove the attempt and say nothing. (Or, if it wanted to be really fancy, it could store a flag the first time saying it has been compressed, and with what algorithm/compression-level, so it would know not to bother trying to do better unless there's been an upgrade). | 16:30 |
| Peng_ | kfogel: Yeah, but then all of that CPU would have been wasted for nothing. | 16:33 |
| kfogel | Peng_: Not in the latter case. But wasting CPU is better than an error message for a non-error in any case! | 16:33 |
| kfogel | :-) | 16:33 |
| gioele | hello | 16:44 |
| Peng_ | kfogel: You could propose the flag thing in the bug. ;-D | 16:53 |
| mozmck_work | in .bzrignore, can I use dir/*.* to ignore everything in certain directories? | 16:54 |
| gioele | I'm experimenting with bzr-svn. Is there a way to make sure that it does not commit anything to the remote svn repository? | 16:54 |
| gioele | mozmck_work: yes | 16:54 |
| Peng_ | gioele: You could not run "commit". | 16:54 |
| Peng_ | mozmck_work: What if the filenames don't have "." in them? | 16:54 |
| jelmer | gioele, don't use the "checkout" or "push" commands | 16:54 |
| Peng_ | mozmck_work: Just ignore dir/ or, if you want to version the directory for some reason, dir/* | 16:54 |
| gioele | jelmer: what about commits? | 16:55 |
| jelmer | gioele, if you commit in a checkout, it'll be committed to the master branch as well | 16:56 |
| jelmer | gioele, if you commit in a standalone branch that was created from a svn branch, it won't affect the branch it was cloned from | 16:56 |
| gioele | jelmer: perfect | 16:56 |
| jelmer | gioele, if the svn repository has a read-only URL you could use that | 16:56 |
| mozmck_work | I tried dir/*.* and then ran "bzr ignored" and it didn't list any files from that dir as being ignored | 16:56 |
| jelmer | that way you're always sure you won't do any writes | 16:56 |
| gioele | jelmer: sadly it has not it. | 16:57 |
| Peng_ | mozmck_work: You do know that ignore rules do not apply to already-versioned files, right? | 16:57 |
| mozmck_work | yes, I'm setting up .bzrignore before I add any files | 16:57 |
| mozmck_work | dir/* didn't work, but dir/ did | 16:58 |
| kfogel | Peng_: it's too obvious; anyone looking seriously at this bug will see all the options. I think the bottleneck is dev attention, not solutions. | 16:58 |
| jelmer | we have a lot of these bugs related to simple unpolished bits of bzr | 16:58 |
| Peng_ | kfogel: Well, I don't think anybody else proposed it. | 16:58 |
| gioele | OK, next topic: how important is it to have svn 1.5 instead of svn 1.4 with regard to bzr-svn? Are there thinks that I can't do when only svn 1.4 is available on the remote repo? | 17:00 |
| dash | svn 1.5 supports revision properties | 17:01 |
| dash | which bzr-svn will used to store metadata | 17:01 |
| dash | on 1.4 and earlier ti uses file properties, which are a little more intrusive | 17:01 |
| awilkins | 1.4 svn repositories support revision properties, but you need to use bzr-svn against the 1.5 API to use them | 17:05 |
| awilkins | gioele: So as long as your CLIENT uses 1.5 or above, you will gain the benefit | 17:06 |
| dash | oh! | 17:06 |
| dash | news to me | 17:06 |
| awilkins | SVN has supported revision properties for as long as I can remember, back to about v 0.39 | 17:07 |
| ddaa | awilkins: I think the news is something like "unprivileged users can now set them at commit time" | 17:29 |
| === mario__ is now known as pygi | ||
| gioele | awilkins, dash: thank you | 17:51 |
| gioele | wow: subvertpy does not provide very useful exceptions: "bzr: ERROR: subvertpy.SubversionException: ("In directory 'svn/branches/src/...'", 155009)" | 18:20 |
| Peng_ | ERR_WC_BAD_ADM_LOG, apparently. | 18:21 |
| SamB | gioele: what, you want it should convert the svn error number into human-readable form? | 18:28 |
| jskulski | hey all, I shelved some changes, and made some changes to my tree (moved functions to a new file) and now bzr unshelve says that it won't be clean. Is there a way I can point it at the new file or get a patch I can apply and delete it from the shelf? | 19:10 |
| verterok | beuno_: ping | 19:43 |
| beuno_ | verterok, hey | 19:43 |
| verterok | beuno_: do you have a minute to chekc verterok.com.ar? | 19:43 |
| beuno_ | verterok, sure | 19:43 |
| === beuno_ is now known as beuno | ||
| verterok | beuno_: it's returning 404's :/ | 19:44 |
| beuno | argh | 19:44 |
| beuno | I must of screwed up migrating | 19:44 |
| beuno | oh | 19:44 |
| beuno | *I* didn't | 19:44 |
| beuno | someone else did | 19:44 |
| verterok | beuno: oh, nice! it's always good to don't be the one who broked it ;) | 19:45 |
| beuno | verterok, DNS FAIL | 19:45 |
| beuno | sorry :( | 19:45 |
| beuno | fixing it now | 19:45 |
| beuno | but it will take an hour or two to propagate | 19:45 |
| verterok | beuno: ok, thanks! | 19:45 |
| verterok | beuno: I noticed because of Bug #394847 | 19:46 |
| ubottu | Launchpad bug 394847 in bzr-eclipse "Update site 404s" [Undecided,New] https://launchpad.net/bugs/394847 | 19:46 |
| beuno | verterok, I can mirror the account on a different server in the mean time if it's critical | 19:47 |
| verterok | beuno: not critical, thanks! | 19:47 |
| Pilky | anyone with any experience with GPL licensing technicalities? I want to know if I write an Obj-C API to hook into bzr, whether I can licence it as LGPL? | 19:48 |
| fullermd | By the standard interpretation, no. | 19:49 |
| Pilky | :/ | 19:50 |
| * Pilky stabs GPL | 19:50 | |
| fullermd | Now, theoretically Canonical owns all the copyrights, so you could potentitally negotiate other terms with them. | 19:53 |
| Pilky | well the only reason is I want to use the API to write a GUI for bzr on OS X | 19:53 |
| Pilky | but I want as much of the code as possible to be licensed as MIT | 19:54 |
| dash | do like bzr-eclipse does and use bzr-xmloutput | 19:54 |
| Pilky | I considered that before but it seems a bit hackish | 19:55 |
| Pilky | using bzrlib I can take python objects and convert them to Obj-C quite easily | 19:56 |
| Peng_ | You can negotiate other terms with Canonical. Well, the website says so; I dunno if anyone ever has. | 19:58 |
| Pilky | yeah I'll probably look into that | 19:59 |
| Pilky | if they allowed my API to be licensed LGPL or even MIT it could help provide a boost for bzr on OS X as a means of talking to other tools | 20:00 |
| Peng_ | Since Canonical owns everything, relicensing would be pretty easy, if they decided to. | 20:01 |
| Pilky | yeah, I mean I'm not looking into relicensing bzr itself | 20:01 |
| beuno | well, it's unlikely that Canonical will relicence bzr to MIT for distribution | 20:01 |
| Pilky | just whether I can create code that talks to bzr lib that doesn't have to be condemned to GPL status | 20:02 |
| dash | more's the pity | 20:02 |
| Peng_ | LGPL is possible... Mercurial is firmly non-LGPL, though, so Bazaar might make the same decision. | 20:02 |
| LarstiQ | Obj-C? | 20:03 |
| LarstiQ | Pilky: you're not at EuroPython by any chance? | 20:03 |
| Pilky | nope | 20:03 |
| LarstiQ | ah ok, pure coincidence then | 20:03 |
| Pilky | how so? | 20:03 |
| LarstiQ | Pilky: there has been at least one talk about python and objc and some interest on the mailing list | 20:04 |
| Pilky | ah cool | 20:04 |
| LarstiQ | and then at least one bof iirc | 20:04 |
| Pilky | well I'm going to be looking into PyObjC for building this bzr API | 20:04 |
| LarstiQ | whereas before that, I hadn't really seen much activity on it | 20:05 |
| * LarstiQ nods at Pilky | 20:05 | |
| Pilky | yeah, a lot of people see Obj-C as some scary weird language, when they get introduced to it and can see that you can talk to cocoa with Python and Ruby as well then they get more interested ;) | 20:05 |
| monteldeonte | Can someone help me with bzr? | 20:05 |
| LarstiQ | Pilky: I feel old now :) | 20:06 |
| dash | monteldeonte: no, you're doomed | 20:06 |
| LarstiQ | monteldeonte: sure, what can we help you with? | 20:06 |
| LarstiQ | dash: oi :P | 20:06 |
| Pilky | heh | 20:06 |
| dash | monteldeonte: (what is your problem? :) | 20:06 |
| monteldeonte | lol | 20:06 |
| monteldeonte | Is there a way that i can sync a bzr branch with svn? | 20:06 |
| Pilky | so yeah, who would be the best person at canonical to get in touch with about my licensing problem? | 20:06 |
| dash | monteldeonte: probably. what's your situation? | 20:06 |
| LarstiQ | monteldeonte: in general, yes, with bzr-svn. There are some corner cases, so as dash said, could you elaborate on your situation? | 20:07 |
| LarstiQ | Pilky: Martin Pool | 20:07 |
| Pilky | ok cool, thanks! | 20:07 |
| monteldeonte | I need to import the SVN from a project, and upload it to a branch | 20:07 |
| monteldeonte | I also need to be able to sync it with the branch | 20:07 |
| monteldeonte | i mean' | 20:08 |
| SamB | Pilky: you can write code and license it under more liberal terms, but if you link it with canonical's code you'd need to provide the source anyway, as per the GPL... | 20:08 |
| monteldeonte | sync the SVN every now and then | 20:08 |
| dash | monteldeonte: sure. install bzr-svn and you can treat svn branches like bzr ones, mostly | 20:08 |
| monteldeonte | dash: I know, i have. I just dont know how to use it | 20:08 |
| Pilky | SamB: well it will remain open source, but I don't want to licence it as GPL as that will limit uptake IMO | 20:08 |
| dash | monteldeonte: 'bzr branch svn://yoursvnurl/.../' | 20:09 |
| LarstiQ | monteldeonte: `bzr branch http://host/svn/repo/path/in/repo/to/branch` | 20:09 |
| SamB | and if this is all Python code we're talking about I frankly don't think it makes a difference | 20:09 |
| monteldeonte | LarstiQ: then how to i update the SVN? | 20:09 |
| dash | monteldeonte: 'bzr push <svn url>' | 20:10 |
| LarstiQ | monteldeonte: if you have commits in your bzr branch you want to get into svn, what dash said | 20:10 |
| LarstiQ | monteldeonte: basically, you can treat svn branches as any other bzr branch | 20:10 |
| SamB | monteldeonte: you just run "bzr pull" in your local copy of the SVN branch | 20:10 |
| fullermd | Y'know, I was just thinking, it's been so boring here lately, let's have a license discussion :p | 20:10 |
| monteldeonte | I mean, when there is a new revision on the SVN, how do i sync it with the branch? | 20:11 |
| SamB | monteldeonte: (it's a good idea to keep a pristine copy of the SVN branch, since SVN makes such a terribly slow DVCS) | 20:11 |
| dash | monteldeonte: 'bzr merge' | 20:11 |
| SamB | then you run "bzr merge ../code-from-svn" | 20:11 |
| SamB | where ../code-from-svn is the pristine bzr copy of the branch SVN branch that you just pulled into | 20:12 |
| monteldeonte | I am sorry, | 20:12 |
| monteldeonte | I dont get it | 20:12 |
| monteldeonte | LarstiQ: Ok, what is the first thing i do | 20:14 |
| LarstiQ | monteldeonte: first, branch from svn. | 20:14 |
| monteldeonte | k, h.o | 20:15 |
| SamB | monteldeonte: basically, bzr-svn just allows Bzr to treat SVN branches as Bzr branches | 20:15 |
| SamB | really, really *slow* Bzr branches | 20:15 |
| LarstiQ | monteldeonte: (you mgith be more comfortable with a checkout style, but we'll come to that later) | 20:15 |
| SamB | and you really don't want to do a bzr checkout directly from SVN | 20:16 |
| SamB | well, maybe a heavyweight one ... | 20:16 |
| LarstiQ | SamB: that, and if you're sitting next to the server... | 20:16 |
| SamB | ... but I've had those fail in mostly-incomprehensible ways | 20:16 |
| SamB | LarstiQ: does that actually help much? | 20:16 |
| SamB | I suppose if it has a 10th or less the round-trip-time as usual ... | 20:17 |
| LarstiQ | SamB: very small latency, lots of bandwidth | 20:17 |
| SamB | LarstiQ: the bandwidth doesn't seem to be much of an issue usually | 20:17 |
| LarstiQ | SamB: talking a gigabit office connection | 20:17 |
| LarstiQ | SamB: are you using tdb or sqlite? | 20:17 |
| SamB | what? I don't actually run any of the SVN repositories I pull from ... or are you talking about bzr-svn's cache? | 20:18 |
| monteldeonte | LarstiQ: OK, now what | 20:19 |
| monteldeonte | Say there is a change in the SVN, how do i get it? | 20:20 |
| SamB | LarstiQ: using tdb or sqlite *where*? | 20:20 |
| monteldeonte | Do i have to do that over again? | 20:20 |
| SamB | monteldeonte: I would suggest keeping that directory just for the stuff from SVN | 20:20 |
| SamB | and use a different one to hold your local branch | 20:21 |
| SamB | which you would create by "bzr branch copy-of-svn my-branch" | 20:21 |
| SamB | monteldeonte: then, when you want to update from svn, you can just go in the one you branched from SVN and run "bzr pull" | 20:21 |
| LarstiQ | SamB: bzr-svn's cache | 20:21 |
| SamB | and you go back to yours and run "bzr merge" | 20:22 |
| monteldeonte | hah! you guys rock! | 20:22 |
| LarstiQ | monteldeonte: SamB's advice is sensible. | 20:22 |
| monteldeonte | I think i got it good now. | 20:22 |
| monteldeonte | LarstiQ: OK, i already have a bzr branch, the one i was updating manually. How do i remove the stuff from that, and put this one into there? | 20:28 |
| monteldeonte | should i just remove it and make a new one? | 20:28 |
| monteldeonte | SamB: ? | 20:29 |
| LarstiQ | monteldeonte: if you intend to use it to interact with svn but didn't produce it with bzr-svn, I'd ditch it if you can | 20:29 |
| monteldeonte | k kool | 20:29 |
| monteldeonte | LarstiQ: the old address for the branch was lp:noxbot now it is lp:~m.deonte/noxbot/main, how do i get that back? | 20:34 |
| LarstiQ | monteldeonte: lp:noxbot is a shorthand, lp:~m.deonte/noxbot/main looks like the expansion for that | 20:35 |
| LarstiQ | monteldeonte: if they no longer match, you can do `bzr pull --remember lp:noxbot` | 20:35 |
| monteldeonte | woo hoo! | 20:38 |
| monteldeonte | LarstiQ: So, when there is a change in the SVN, all i do is bzr pull and then bzr push? | 20:40 |
| LarstiQ | monteldeonte: as long as svn and local don't diverge, yes | 20:40 |
| LarstiQ | monteldeonte: if they do, you need `bzr merge` | 20:41 |
| monteldeonte | LarstiQ: Diverge? | 20:41 |
| LarstiQ | monteldeonte: SamB outlined a workflow for that | 20:41 |
| LarstiQ | monteldeonte: say if you commit something locally, and someone commits something in svn | 20:41 |
| LarstiQ | monteldeonte: neither is then anymore a strict superset/subset of the other | 20:41 |
| monteldeonte | Wait, so if this guy commits on SVN, | 20:42 |
| monteldeonte | What do i do? | 20:42 |
| LarstiQ | monteldeonte: first, `bzr pull` | 20:42 |
| monteldeonte | then | 20:42 |
| LarstiQ | monteldeonte: then, if it says you need to use `bzr merge`, that | 20:43 |
| monteldeonte | Oh, it will tell me? | 20:43 |
| LarstiQ | monteldeonte: as SamB said, I'd advise to keep one local mirror you only pull into, and only commit just before you synchronise with svn | 20:43 |
| LarstiQ | monteldeonte: yes | 20:43 |
| LarstiQ | monteldeonte: and use a local branch of that mirror to do actual work | 20:43 |
| monteldeonte | LarstiQ: OK, so when someone gets this branch, how do they update it? | 20:45 |
| LarstiQ | monteldeonte: just the usual pull/merge. Other than svn, are you familiar of how bzr works? | 20:47 |
| LarstiQ | s/of/with/ | 20:47 |
| monteldeonte | not really. | 20:48 |
| LarstiQ | ok | 20:49 |
| monteldeonte | LarstiQ: Wait, so will that other person have to have brz-svn installed? | 20:49 |
| LarstiQ | monteldeonte: if they interact only with your bzr branch? No. | 20:49 |
| SamB | monteldeonte: only if they also want to pull from SVN | 20:49 |
| SamB | well, merge is more like it | 20:49 |
| LarstiQ | monteldeonte: if they want to communicate directly with svn, then yes | 20:49 |
| monteldeonte | OK, so say someone downloads my branch. When i push to bzr, what do they do to get it? | 20:51 |
| LarstiQ | monteldeonte: bzr pull | 20:52 |
| monteldeonte | Will that pull from the SVN? | 20:52 |
| LarstiQ | monteldeonte: no, from the same location they got your branch | 20:53 |
| monteldeonte | shweet | 20:53 |
| LarstiQ | monteldeonte: In case you hadn't seen it yet, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html | 20:53 |
| LarstiQ | monteldeonte: I have to go now unfortunately (well, drinking beer) | 20:54 |
| LarstiQ | monteldeonte: so good luck and I'll check in when I get back | 20:54 |
| monteldeonte | Ok, thank you for your help | 20:54 |
| monteldeonte | I think i get it now | 20:54 |
| monteldeonte | Ok, thansk | 20:54 |
| LarstiQ | good | 20:54 |
| gioele | I cannot understand the wording of section 8.2.3: it first gives an example using 'svn-import', then says 'Here's the recipe from above updated to use a central Bazaar mirror:' adn then gives and example where svn-import is not mentioned | 21:18 |
| gioele | section 8.2.3 == http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#bzr-svn | 21:19 |
| Peng_ | gioele: Well, use "bzr svn-import" to import all the branches from a repo. Use "bzr branch" for one branch. | 21:19 |
| Peng_ | gioele: The end result is equivalent; svn-import just makes it easier to import multiple branches at once. | 21:20 |
| gioele | Peng_: from what I see the leading text should say "In addition to svn-import, also XXX can be used to create a central Bazaar mirror. Here is the recipe from above updated to use method XXX" | 21:24 |
| Peng_ | Ehh. I don't have documentation paged into my brain. | 21:26 |
| gioele | Peng_: well, as I wrote, my comment was about the "wording" of that section | 21:27 |
| Peng_ | I such at English. | 21:28 |
| fbond | Hi. I was just thinking -- there's been some talk of support for history editing on the ML. Would it make sense at all to build this around shelve, instead of following the rebase model? | 21:46 |
| fbond | Some automation on top of shelve would get me just about everything I would want... | 21:46 |
| mozmck_work | I've used git just a little. It looks like a git branch is about equivalent to a bzr tag - right? | 21:47 |
| gioele | in bzr help svn-layout there is an example of a custom repository layout. It uses a new section inside ~/.bazaar/subversion.conf. The example use "[203ae883-c723-44c9-aabd-cb56e4f81c9a]". How do I know which number should I put there for my repository? | 21:47 |
| garyvdm | mozmck_work: No - because a tag does not move forward when you commit. | 21:48 |
| mozmck_work | hmmm, what does that mean? | 21:48 |
| dash | a bzr tag is just a name for a revision | 21:49 |
| mozmck_work | I see. | 21:49 |
| mozmck_work | in git you can have say a release branch and the main dev branch "master" | 21:49 |
| jocr | !help | 21:49 |
| ubottu | Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots | 21:49 |
| mozmck_work | and change between them in the same working directory with a simple command | 21:50 |
| dash | mozmck_work: right. the normal bzr workflow is two separate dirs | 21:50 |
| dash | but you can use 'bzr switch' if you really want to use the same working copy. | 21:50 |
| mozmck_work | that was my next question! | 21:51 |
| mozmck_work | I don't know yet which I would prefer. | 21:51 |
| mozmck_work | if you have 2 branches I guess they can go in the same repository. | 21:52 |
| dash | that's what repos are for | 21:52 |
| mozmck_work | thanks. I'm slowly figuring it out - I think... | 21:54 |
| jocr | where can I find information about how bzr deals with merge conflicts. I haven't been able to find the right documentation yet. | 21:56 |
| garyvdm | jocr: what do you want to know? | 21:57 |
| a_c_m | anyone know of any php libs or apps that can browse a bzr repro ? | 21:57 |
| jocr | I see a bunch of suffixes on files that had conflicts and I just wanted to know which file was what | 21:57 |
| jocr | suffixes are like BASE or BASE.moved or OTHER | 21:58 |
| Peng_ | a_c_m: This was discussed a bit on the mailing list recently. | 22:00 |
| a_c_m | Peng_: ahh cool any good conclusions, or is there somewhere online the mailing list is stored? | 22:00 |
| Peng_ | a_c_m: The answer was "no", and yes, but I don't have a link handy. :P | 22:01 |
| * Peng_ goes to eat. | 22:02 | |
| Peng_ | Sorry! | 22:02 |
| a_c_m | Peng_: shame :( | 22:02 |
| fbond | window goto (st | 22:02 |
| fbond | Whoops. | 22:02 |
| jocr | !BASE | 22:03 |
| ubottu | Sorry, I don't know anything about BASE | 22:03 |
| jocr | !.BASE | 22:03 |
| garyvdm | jocr: sorry - I can find any docs - allthough I'm sure that there are. | 22:04 |
| jocr | that's o.k. I'll keep looking | 22:04 |
| garyvdm | .THIS is the file from the branch that you merged into | 22:04 |
| garyvdm | .OTHER is the file from the branch that you merged from | 22:04 |
| gioele | jocr: bzr help conflicts | 22:04 |
| gioele | (in general bzr help topics is quite helpful) | 22:04 |
| garyvdm | .BASE is the version of the file that both branches have is common. | 22:05 |
| jocr | I see, I was starting to deduce all this but thanks for the help. | 22:07 |
| jocr | Another question is if I get a version of the file that I want to keep, say the .BASE version do I delete the others and to bzr resolve to fix the conflict? | 22:07 |
| garyvdm | rm foo | 22:08 |
| garyvdm | mv foo.BASE foo | 22:08 |
| garyvdm | bzr resolve foo | 22:08 |
| jocr | I see thanks again. and thanks gioele, I'll read the help file here | 22:09 |
| garyvdm | All though it's very unlikely that you want to keep the BASE | 22:09 |
| garyvdm | If it's a binary file, you generally keep the THIS or the OTHER | 22:10 |
| jocr | no it's a source file with some different fixes in both versions | 22:10 |
| jocr | that is the THIS and OTHER versions | 22:10 |
| lifeless | moin | 22:30 |
| RenatoSilva | where can I see the source of builtins.tree_files(file_list) | 22:34 |
| bob2 | bzrlib/builtins.py | 22:36 |
| garyvdm | bzrlib/builtins.py line 71? | 22:36 |
| RenatoSilva | bzrlib is at? | 22:37 |
| garyvdm | root of bzr.dev | 22:38 |
| RenatoSilva | I can't find it in bzr home | 22:38 |
| RenatoSilva | what is bzr.dev | 22:38 |
| garyvdm | Trunk of bzr | 22:39 |
| garyvdm | http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head%3A/bzrlib/builtins.py#L70 | 22:40 |
| RenatoSilva | what are the .pyd files? | 22:40 |
| RenatoSilva | garyvdm: thanks | 22:40 |
| RenatoSilva | I need to browse over the code | 22:41 |
| RenatoSilva | it's just bzr branch lp:bazaar/trunk, right? | 22:42 |
| garyvdm | bzr branch lp:bzr | 22:42 |
| RenatoSilva | ok | 22:44 |
| RenatoSilva | Does anyone suspect how can Programação become into Programa‡Æo? | 22:44 |
| garyvdm | The text is bing decode in the wrong charset | 22:45 |
| garyvdm | *being | 22:45 |
| RenatoSilva | It's what comes from WorkingTree.id2abspath | 22:45 |
| RenatoSilva | I'm trying stuff like print u'Programação'.encode('latin-1').decode('cp850') | 22:46 |
| RenatoSilva | Without sucess, none of them lead to the above string | 22:46 |
| dash | try removing the decode? | 22:46 |
| dash | it's probably just latin-1 | 22:46 |
| lifeless | RenatoSilva: python -c 'import bzrlib; print bzrlib.__path__' will tel you where bzrlib is being loaded from | 22:47 |
| RenatoSilva | dash: tried | 22:47 |
| RenatoSilva | dash: how can Programação become into Programa‡Æo? | 22:48 |
| RenatoSilva | dash: that's what I mean | 22:48 |
| Peng_ | Is it a bad idea for multiple, completely unrelated projects to use the same file IDs? | 22:52 |
| lifeless | Peng_: it would be odd | 22:53 |
| lifeless | Peng_: not necessarily bad; why? | 22:53 |
| RenatoSilva | hum, what is this: http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1127 | 22:54 |
| Peng_ | lifeless: bzr-git does it. I was just curious. | 22:55 |
| RenatoSilva | How can Bzr guess that the string is either unicode or utf-8 encoded? | 22:55 |
| lifeless | Peng_: it does? | 22:55 |
| lifeless | Peng_: what algorithm? | 22:55 |
| RenatoSilva | when it is str, it is not necessarily utf-8 encoded right? | 22:55 |
| Peng_ | lifeless: It just uses the file's relative path. | 22:56 |
| lifeless | RenatoSilva: that function isn't guessing | 22:56 |
| jelmer | Peng_: Well, with some escaping | 22:56 |
| Peng_ | jelmer: Oh. | 22:56 |
| Peng_ | Hi jelmer. :D | 22:56 |
| Peng_ | I guess you have to do that because Git doesn't have convenient repository UUIDs like svn? | 22:56 |
| RenatoSilva | lifeless: because the user should call it only for such cases? | 22:56 |
| jelmer | Peng_, right | 22:56 |
| lifeless | RenatoSilva: first it checks if it *is* unicode, and if its not unicode it expects to be given a utf8 str | 22:56 |
| jelmer | Peng_: And I could use the sha of the path or something like that | 22:57 |
| lifeless | RenatoSilva: yes, we use utf8 for our disk data structures | 22:57 |
| jelmer | Peng_, But that would just cause indirection because there wouldn't be a way to go from file id to path cheaply | 22:57 |
| lifeless | RenatoSilva: and we use that function when handling deserialisation from them | 22:57 |
| RenatoSilva | lifeless: so it *expects*, it should not be called for non-utf-8 | 22:57 |
| lifeless | RenatoSilva: thats right | 22:57 |
| Peng_ | jelmer: Would it be possible to include the revision ID that introduced the file? | 22:58 |
| Peng_ | bzr-svn does that, IIRC? | 22:58 |
| jelmer | Peng_: That would be possible, but expensive, and there's no point | 22:58 |
| lifeless | jelmer: does it prefix it with git: or something? | 22:58 |
| lifeless | jelmer: there is a point | 22:58 |
| RenatoSilva | lifeless: it seems the problem is in WorkingTree then | 22:58 |
| Peng_ | lifeless: No prefix. | 22:58 |
| lifeless | jelmer: consider a repo with any projects; the per-file graph is often loaded in bulk by bzr (e.g. for annotate) | 22:58 |
| RenatoSilva | lifeless: http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/workingtree.py#L204 | 22:59 |
| lifeless | jelmer: having the same fileid in many projects with do very odd things to the per-file graph size and index shape | 22:59 |
| lifeless | s/with/will/ | 22:59 |
| Peng_ | lifeless: Will it actually cause problems, though? | 22:59 |
| Peng_ | lifeless: I mean, errors? | 22:59 |
| RenatoSilva | lifeless: it also expects utf-8 or unicode | 22:59 |
| lifeless | Peng_: it will cause slowness | 23:00 |
| jelmer | lifeless: if we have to include the revision sha in which a file was introduced it means different slowness | 23:00 |
| jelmer | lifeless, because we can't just fetch an arbitrary tree and know the file ids in it, we have to search history | 23:01 |
| Peng_ | How does bzr-svn do it? | 23:01 |
| jelmer | Peng_: It searches history, and caches heavily | 23:01 |
| Peng_ | jelmer: Why have bzr-svn and bzr-git do it differently? | 23:02 |
| lifeless | jelmer: tree-1 in the target will know, and it should be cheap to access | 23:02 |
| lifeless | jelmer: also, do you do rename heuristics at import? | 23:02 |
| jelmer | lifeless, we don't necessarily have tree-1 | 23:02 |
| jelmer | lifeless, we don't do rename heuristics yet | 23:02 |
| jelmer | lifeless, when we do, I agree it would make sense to start looking at this | 23:02 |
| lifeless | I suspect your file id allocation will mean you cannot do file rename heuristics :> | 23:02 |
| jelmer | lifeless, That's not a problem | 23:02 |
| jelmer | lifeless, We can't introduce rename heuristics without changing the mapping anyway | 23:03 |
| jelmer | lifeless: so if we have to change the mapping anyway, we might as well change the file id allocation | 23:03 |
| lifeless | ok, good | 23:03 |
| jelmer | and introduce all of the infrastructure to deal with more complex file ids | 23:03 |
| lifeless | because, at the moment, bzr-git repos of all of ubuntu will behave terribly. | 23:04 |
| jelmer | Peng_: bzr-svn does roundtripping, bzr-git does not | 23:04 |
| jelmer | lifeless: right | 23:04 |
| lifeless | RenatoSilva: is WorkingTree.open() being called with a str, rather than a unicode ? | 23:05 |
| lifeless | bbs | 23:05 |
| Peng_ | jelmer: Why doesn't bzr-git do roundtripping? | 23:05 |
| jelmer | Peng_: The effort hasn't been put in and there's no really good place to put the bzr metadata | 23:05 |
| RenatoSilva | lifeless: I'm trying to look at the right file, brb | 23:05 |
| jelmer | Peng_, The only real place is the git commit message, and that's a bit intrusive | 23:05 |
| RenatoSilva | lifeless: tree = WorkingTree.open_containing(default_branch)[0] | 23:06 |
| lifeless | default_branch should have been decoded by the command argument parser from your console encoding | 23:06 |
| RenatoSilva | lifeless: def tree_files(file_list, default_branch=u'.', canonicalize=True, | 23:07 |
| RenatoSilva | lifeless: tree, file_list = builtins.tree_files(file_list) | 23:08 |
| Peng_ | jelmer: ok :) | 23:08 |
| RenatoSilva | lifeless: i.e. default_branch is '.' however the complete path is returned in output | 23:08 |
| lifeless | RenatoSilva: yes, that shuold all be fine; u'.' when passed to the file system means we get a filesystem encoding decoded cwd | 23:10 |
| mathrick | who could give me some help with implementing rebase --interactive support? | 23:12 |
| mathrick | ie. retroactive history shaping | 23:12 |
| dash | mathrick: evil | 23:12 |
| mathrick | dash: how else am I supposed to submit clean patches to projects? | 23:13 |
| RenatoSilva | lifeless: I think that the path comes from tree = WorkingTree.open_containing(osutils.realpath(file_list[0]))[0] | 23:13 |
| dash | mathrick: what's wrong with diff | 23:13 |
| dash | mathrick: i assume you mean non-bzr projects? | 23:13 |
| mathrick | dash: I mean bzr projects | 23:14 |
| lifeless | RenatoSilva: it could as well, yes. | 23:14 |
| mathrick | non-bzr ones of course get plain diffs | 23:14 |
| dash | mathrick: then why would it matter? | 23:14 |
| dash | mathrick: send a bundle | 23:14 |
| lifeless | RenatoSilva: are you on windows? | 23:14 |
| mathrick | dash: then I can't split them into featuresets and comment each one in a separate mail | 23:14 |
| mathrick | which is the preferred form for very many projects | 23:14 |
| mathrick | including, I believe, bzr :) | 23:15 |
| dash | mathrick: why'd you do multiple features in a single branch? :) | 23:15 |
| lifeless | mathrick: its nice to get clean featuresets; its more important to get patches though :) | 23:15 |
| mathrick | dash: no, it's for bigger patches implementing a single feature / set of related features | 23:15 |
| dash | I just finished breaking up a gigantic change into about 5 separate feature sets | 23:15 |
| dash | but i used loom and it's for syncing one SVN repo to another | 23:16 |
| RenatoSilva | lifeless: yes | 23:16 |
| RAOF | You could do that with bzr merge cherrypicking, assuming each commit contains a single feature. | 23:16 |
| lifeless | RenatoSilva: what bzr version do you have? | 23:16 |
| poolie | hello all | 23:16 |
| dash | mathrick: right, that sounds like a mistake to me | 23:16 |
| mathrick | dash: howso? | 23:16 |
| RenatoSilva | lifeless: I think that there may be a problem in http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1127 | 23:16 |
| lifeless | hi poolie | 23:16 |
| lifeless | RenatoSilva: what bzr version are you using? | 23:17 |
| dash | mathrick: I don't see the problem with one branch and one merge per feature | 23:17 |
| RenatoSilva | lifeless: ignore the line please, I mean realpath method | 23:17 |
| mathrick | dash: the point is that a single feature should be multiple patches when it's big enough | 23:17 |
| dash | mathrick: yeah, i don't really believe that | 23:17 |
| mathrick | but it happens | 23:18 |
| mathrick | case in point, wine's DIB engine | 23:18 |
| dash | heh | 23:18 |
| mathrick | they have specifically rejected patches which did that as a single "all-in-one" dump before | 23:18 |
| RenatoSilva | lifeless: 1.15 | 23:18 |
| lifeless | mathrick: what dash is saying is that you should do each component in a separate branch | 23:18 |
| RenatoSilva | lifeless: in tree = WorkingTree.open_containing(osutils.realpath(file_list[0]))[0] | 23:18 |
| lifeless | RenatoSilva: please try bzr 1.16 | 23:19 |
| RenatoSilva | lifeless: something is going wrong... | 23:19 |
| lifeless | bialix recently changed the command interpreter to decode all arguments to unicode | 23:19 |
| lifeless | for problems like that | 23:19 |
| mathrick | lifeless: but that's not how it happens. That's precisely the point, I can't know what I will end up implementing before I start | 23:19 |
| RenatoSilva | lifeless: is there a windows installer for 1.16? | 23:19 |
| dash | mathrick: waiting until all your changes are done seems like a poor time to break stuff up | 23:19 |
| lifeless | RenatoSilva: I don't know, have a look :) | 23:19 |
| lifeless | mathrick: I know, and I agree. | 23:19 |
| dash | mathrick: i'm not saying you have to know before you start | 23:20 |
| lifeless | mathrick: we want tools to do this; that doesn't actually imply rebase though it can be used if you haven't published your code. | 23:20 |
| mathrick | lifeless: I only used the shorthand because that's where it is in git, which is well-known | 23:20 |
| dash | just that once you know, put your unrelated changes into a different branch :) | 23:20 |
| lifeless | I wrote a manifesto about this a few weeks back | 23:20 |
| mathrick | I don't want to imply it should be inside bzr rebase | 23:20 |
| mathrick | lifeless: link? | 23:21 |
| mathrick | and that's exactly what I want, to give tools | 23:21 |
| RenatoSilva | lifeless: downloading... | 23:21 |
| lifeless | mathrick: https://lists.ubuntu.com/archives/bazaar/2009q2/059263.html | 23:21 |
| lifeless | breakfasting | 23:21 |
| mathrick | dash: the historical patch order is never the same as logical. Forgotten files and stupid typos happen. I want tools to be able to reshape that easily, instead of devolving to a bunch of dirs with branches and fighting with diff | 23:22 |
| mathrick | lifeless: oh good, that seems interesting. I was actually wondering myself about being able to edit it without losing the actual patches as they happened | 23:23 |
| dash | mathrick: and my point is that the historical patch order is also important, and some people are altogether too eager to destroy that. :) | 23:23 |
| mathrick | dash: that's another problem that needs solving, not denying the problem #1 doesn't exist | 23:23 |
| mathrick | s/doesn't// | 23:23 |
| mathrick | also, it should help / interplay with how I wanted loom to work (as opposed to how it actually works today( | 23:24 |
| dash | mathrick: I just think the prevalence of that particular problem is overstated | 23:24 |
| RenatoSilva | installed but the same error: bzr xmlstatus > file is returning <?xml version="1.0" encoding="UTF-8"?><status workingtree_root="C:/Programa‡Æo/"></status> | 23:24 |
| mathrick | dash: I don't think so. If I want to present patches in a logical order, my VCS gives me absolutely no tools above diff. That's not the brave new world we were supposed to have with DVCS | 23:25 |
| dash | who says? :) | 23:25 |
| mathrick | it's silly that it's distributed and facilitates the exchange easily except for when you want to send patches by email and discuss them | 23:26 |
| mathrick | dash: says what? | 23:26 |
| dash | mathrick: what we were supposed to have | 23:26 |
| mathrick | dunno. I see a problem the tool fails to solve | 23:26 |
| RenatoSilva | lifeless: maybe C:/Programa‡Æo comes from encoding as cp1252 when it's expected cp850 | 23:26 |
| mathrick | can we retroactively send brimstone upon the inventors of codepages? | 23:27 |
| RenatoSilva | lifeless: something in the chain guess that it should be cp1252, but it should not according to chcp command. If I run chcp 1252 before it, then the file chars are ok | 23:28 |
| dash | mathrick: if we could, it would have already happened | 23:28 |
| mathrick | dang | 23:28 |
| RenatoSilva | * is guessing | 23:28 |
| === omichael is now known as omichael_afk | ||
| RenatoSilva | maybe the problem is here http://bazaar.launchpad.net/%7Ebzr/bzr/trunk/annotate/head%3A/bzrlib/osutils.py#L1058 | 23:34 |
| === omichael_afk is now known as omichael | ||
| mathrick | lifeless: I don't understand the "Integration" section | 23:42 |
| lifeless | is the file on disk encoded in cp1252/ | 23:47 |
| lifeless | ? | 23:47 |
| lifeless | RenatoSilva: ^ | 23:47 |
| lifeless | RenatoSilva: please file a bug about this; it could be a bug in bzr-eclipse, xmloutput or bzr, or even just a wrongly encoded filename on disk | 23:48 |
| RenatoSilva | lifeless: yeah, it could be a bug in many places hehe | 23:52 |
| RenatoSilva | lifeless: the file is created by > as latin-1, which is covered by cp1252 afaik | 23:53 |
| RenatoSilva | lifeless: there no workaround to do, unless there is a way to make an _actual_ encoding conversion | 23:56 |
| RenatoSilva | * there is | 23:56 |
| RenatoSilva | WorkingTree.id2abspath is returning an unicode string from a non-utf-8 encoding | 23:56 |
| RenatoSilva | the terminal expects to receive a cp850 output, and treats it as that, then put that in file | 23:58 |
| RenatoSilva | well, actually it is cp850 | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!