| MTecknology | how can I make a patch file for binary changes? | 07:21 |
|---|---|---|
| Peng_ | MTecknology: You can't with bzr, but "bzr send" does include binary data in a base64-encoded block at the end (along with other stuff). | 07:23 |
| MTecknology | Peng_: oh, I have a source_A and a source_B which is source_A + changed; I want to apply the changes from the two onto source_C | 07:25 |
| Peng_ | MTecknology: ......"bzr merge"? | 07:25 |
| MTecknology | I don't know what the actual changes are though :P | 07:26 |
| Peng_ | OK, I'm way to sleepy to understand this conversation, sorry. | 07:27 |
| MTecknology | Peng_: aight - I should head that way too | 07:28 |
| === kirkland` is now known as kirkland | ||
| === radoe_ is now known as radoe | ||
| radoe | How do I get rid of the remembered locations from pull/push --remember? | 08:47 |
| lifeless | you can edit .bzr/branch/branch.conf | 08:54 |
| lifeless | or just --remember a better url | 08:54 |
| * mtaylor pokes lifeless | 09:46 | |
| Lor | Still continuing about the uniqueness of file-ids: a special metadata file should have a file-id that is uniquely determined by the id of the tree root. | 09:55 |
| jelmer | Lor: I'm not sure if that's necesarily a good idea | 09:56 |
| Lor | So we want the metadata files to have distinct ids when they are in unrelated branches (to avoid collisions in joins), but if the same metadata file is created two times in related branches, they should have the same id. | 09:56 |
| jelmer | what would happen in the case of nested trees, in which case multiple versions of this file could exist in different trees? | 09:56 |
| jelmer | (file ids need to be unique)_ | 09:56 |
| Lor | Those different trees must have distinct tree root ids anyway. | 09:56 |
| Lor | That's the whole point of rich-root, iiuc. | 09:57 |
| jelmer | Lor: Sure, but all of the files in those trees also must have unique file ids | 09:57 |
| jelmer | Lor: So if e.g. .bzrmeta always had the same file id then it would make it impossible for nested trees to contain .bzrmeta | 09:57 |
| Lor | No, .bzrmeta will have an id that is in one-to-one relation with the id of the tree root. | 09:58 |
| Lor | So each distinct subtree (with a distinct id) will also have a distinct id for .bzrmeta | 09:58 |
| jelmer | Lor: in that case, what's the point of having a constant file id? | 09:58 |
| Lor | The point is that if a plugin creates the metadata file in two related branches, then there won't be a path collision (only a text collision, which can be handled) when the branches are merged. | 09:59 |
| jelmer | Lor: That's a problem with all sorts of parallel imports, not really specific to the issue you're raising. | 10:00 |
| jelmer | I think we should just handle that situation better in general | 10:00 |
| Lor | Yes, true. | 10:00 |
| Lor | But metadata files have clearer identities than random imported stuff. | 10:00 |
| Lor | It's better to avoid assigning two file-ids to what is known to be a single logical file identity, when that is possible. | 10:01 |
| jelmer | Lor: You should be able to already specify a manual file id if you know how to generate it though | 10:03 |
| Lor | Yes, obviously it is possible. | 10:03 |
| Lor | I'm talking about what should be the convention for plugin authors when they create metadata files. | 10:03 |
| Lor | Especially if .bzrmeta is to be used by everyone, then it would be good that whoever first creates .bzrmeta gives it the "right" file-id. | 10:05 |
| jelmer | Lor: I think if it's considered a good idea to have a common file id for that directory, we should add a convenience method to bazaar that creates that directory for you | 10:07 |
| jelmer | it can then also take care of assigning the right file id, etc | 10:08 |
| Lor | Right. | 10:08 |
| clbr | i'm looking for a way to only merge certain revisions from branch A into branch B (or excluding some). I'm wondering if this is conceptually possible? | 10:11 |
| jelmer | clbr: hi | 10:13 |
| clbr | hi | 10:13 |
| jelmer | clbr: yep, you can specify individual revisions to merge using -c or -rR1..R2 to merge a range of revisions | 10:13 |
| clbr | thx, this was easy :-) | 10:14 |
| clbr | I'll try if I get the results I expect | 10:15 |
| Lor | Incidentally, is there some rationale available for bzr's handling of clean ambiguous merges? | 10:15 |
| Lor | hg decides to treat them as conflicts, whereas bzr sees no problem | 10:16 |
| Lor | bzr's approach is certainly more practical, but hg seems to Do The Right Thing | 10:17 |
| mwhudson | Lor: what do you mean by "clean ambiguous merge" ? | 10:17 |
| Lor | The same change being done in two distinct branches, which then get merged. | 10:17 |
| mwhudson | bzr's default merger is based on a majority voting three way merge i think | 10:18 |
| Lor | Yes, but _why_ do it this way? | 10:20 |
| Lor | hg docs provide a rationale for their choice | 10:21 |
| Lor | I'd like to see something similar for bzr | 10:21 |
| mwhudson | dunno really | 10:21 |
| mkanat | Lor: Personally, I'd be extremely annoyed if identical changes showed up as a conflict. | 10:24 |
| Lor | I can't find the rationale from ht docs right now, but here's how it went: | 10:24 |
| Lor | Suppose that in the original you have: | 10:25 |
| Lor | #define NUM_THINGIES 3 | 10:26 |
| Lor | enum { FOO, BAR, BAZ } Thingy; | 10:26 |
| Lor | (Those lines might be in completely different places) | 10:26 |
| Lor | In THIS you have: | 10:26 |
| Lor | #define NUM_THINGIES 4 | 10:26 |
| Lor | enum { FOO, BAR, BAZ, QUUX } Thingy; | 10:26 |
| Lor | and in OTHER you have: | 10:26 |
| Lor | #define NUM_THINGIES 4 | 10:26 |
| Lor | enum { FOO, BAR, BAZ, FNORD } Thingy; | 10:27 |
| Lor | After the merge, we _don't_ want to have #define NUM_THINGIES 4 | 10:27 |
| mkanat | Lor: That will conflict anyway, though. | 10:28 |
| mkanat | Lor: Because the enum line isn't the same. | 10:28 |
| mkanat | Lor: Oh, I see what you mean, though. | 10:28 |
| Lor | I'm talking about the #define line. | 10:28 |
| Lor | It might be far away from the enum. | 10:28 |
| mwhudson | Lor: but there are always going to be cases where a clean merge doesn't mean working code | 10:28 |
| Lor | Also, the items of the enum line might be listed one per line. Then an automatic merge could handle it. | 10:28 |
| Lor | True enough. | 10:29 |
| mkanat | Lor: Yeah, I think that case is uncommon enough that I'd rather have it merge for me. | 10:29 |
| mkanat | Lor: Given that otherwise, in some branches I'd be getting literally hundreds of conflicts on merge. | 10:29 |
| Lor | But that's because your changes do have a common origin that the version control system just can't track? | 10:30 |
| Lor | If you just apply a patch to two branches, then bzr won't have any way of knowing that the changes are really the "same" change. | 10:31 |
| mkanat | Lor: Yes, I actually had a discussion about this the other day with folks here. | 10:31 |
| Lor | Did darcs come up? :) | 10:32 |
| mkanat | Lor: Ha. No, DaggyFixes did. | 10:32 |
| mkanat | Lor: But I think DaggyFixes is a bad, hackish solution. | 10:32 |
| mkanat | And also one that isn't broadly-applicable enough to development processes to work. | 10:32 |
| Lor | Darcs tries very hard to Do The Right Thing. | 10:32 |
| mwhudson | Lor: have you seen http://github.com/droundy/iolaus ? | 10:32 |
| mkanat | Lor: Actually, though, bzr doesn't worry about *identical* patches. | 10:33 |
| mkanat | Lor: It handles those fine, now. So that's why those merges are good for me. | 10:33 |
| Lor | Yes, well, obviously it is impossible for a non-semantics-aware tool to guarantee that the result of a merge makes any sense. | 10:36 |
| Lor | It's just a question of what level of imperfection to strive for. | 10:37 |
| mkanat | Lor: Well, I think it's more of a matter of what's the most practical for the majority of users. | 10:37 |
| mkanat | Lor: That is, if it's a question that can't be solved for 100% of them in all cases. | 10:37 |
| Lor | iolaus seems pretty neat | 10:40 |
| Lor | The semantics of darcs with the performance of git would be a sweet combo. | 10:41 |
| Lor | (Still, I'm not very fond of git.) | 10:41 |
| mwhudson | you could do something similar for bzr i think, the model is similar enough | 10:42 |
| Lor | loom and pipeline are the first steps in that direction | 10:45 |
| mwhudson | well | 10:47 |
| mwhudson | a similar direction i guess | 10:47 |
| Lor | Those require you to specify the dependencies explicitly, and with coarser granularity, and the dependencies form a list and not a full graph. But anyway. | 10:48 |
| spiv | Lor: the rationale for clean merges when both sides make the same change is: | 11:03 |
| spiv | a) if both sides agree then it's probably what you want, and | 11:03 |
| spiv | b) it makes coping with cherrypicks much more pleasant | 11:03 |
| spiv | e.g. the scenario of backporting a particular fix from trunk to a stable release branch, but then later merging that release branch back into trunk. | 11:04 |
| Lor | Yes, but that seems like a symptom of the fact that the history of cherry-picks isn't tracked. | 11:04 |
| spiv | Sure. | 11:05 |
| spiv | If you want it'd probably be not too hard to provide a plugin to trigger conflicts in this case. | 11:06 |
| Lor | True enough. | 11:07 |
| spiv | Oddly enough users most don't ask for more conflicts ;) | 11:08 |
| spiv | Kind of related: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/hooks.html#example-a-merge-plugin | 11:08 |
| Lor | Yes, I just wrote one. | 11:09 |
| Lor | A trivial one, though: the metadata file is recreated during commit, so the merge hook doesn't need to do anything except notify that there is no conflict. | 11:09 |
| spiv | *nod* | 11:10 |
| Lor | Anyway, there should also be subsume- and extract-hooks. | 11:12 |
| Lor | Or, preferably, versioned per-entry metadata, so it gets moved automatically during a join or split. | 11:12 |
| wgrant | With bzr 2.1.1 and bzr-git 0.4.3 on Lucid, attempting to branch from a git://... URL crashes like http://paste.ubuntu.com/432198/ | 13:11 |
| wgrant | Any hints? | 13:11 |
| parthm | jam: https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483 | 13:13 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| Lor | Is it a policy that every distinct plugin hosted by launchpad should have its own project? | 14:02 |
| Lor | Even if it's just a single file? | 14:02 |
| jelmer | wgrant: that's the bug I was talking about earlier with upstream python changing behaviour | 14:04 |
| jelmer | wgrant: doing an SRU for that is on my todo list for this week | 14:04 |
| Lor | Also, what's the preferred way to share code between plugins? | 14:08 |
| maxb | Lor: The way Launchpad, especially its automatic stacked branches, works, makes it very much preferable for there to be 1 project per group of branches sharing history. | 14:11 |
| maxb | That pretty much implies 1 project per plugin | 14:11 |
| Lor | Not really. | 14:12 |
| Lor | I could develop several plugins in a single branch. | 14:12 |
| Lor | And have a project that covers all those plugins. | 14:12 |
| jelmer | Lor: that makes it hard to check out those plugins though | 14:12 |
| Lor | It seems a bit ugly, but it would allow straightforward code sharing. | 14:12 |
| Lor | Hard to check out? How? | 14:13 |
| jelmer | Lor: you can't just run "bzr branch lp:foo ~/.bazaar/plugins/foo" anymore | 14:13 |
| Lor | Well, I never do that anyway, I create explicit symlinks. | 14:13 |
| Lor | I think it's bad style to have any real content in dot-directories. | 14:13 |
| Lor | Well then, it is also possible to just develop a single plugin (a single directory, that is), that provides lots of unrelated functionality. | 14:14 |
| Lor | Like bzrtools. | 14:14 |
| Lor | Is that considered bad style? | 14:15 |
| jelmer | Lor: it depends on the tools I guess | 14:15 |
| jelmer | Lor: the stuff in bzrtools is all quite small so the maintainance overhead probably doesn't make it worth having separate plugins | 14:16 |
| Lor | I just wrote a plugin that is 143 lines. | 14:16 |
| Lor | It doesn't quite seem worth its own project. | 14:16 |
| jelmer | Lor: what does it do? | 14:16 |
| Lor | It records mtimes of modified files in .bzrmeta/mtimes | 14:17 |
| jelmer | Lor: I think that probably deserves its own file | 14:17 |
| jelmer | *plugin | 14:17 |
| Lor | I find myself defining lots of general-purpose auxiliary functions that bzrlib doesn't provide. I'd like to use those in other plugins, too. | 14:18 |
| spiv | Lor: projects are cheap ;) | 14:18 |
| Lor | What do I do? | 14:18 |
| jelmer | Lor: can you give examples of those auxiliary functions? | 14:18 |
| jelmer | I haven't noticed that so far | 14:18 |
| spiv | Lor: submit patches to bzrlib! | 14:18 |
| jelmer | or not anymore, rather :-) | 14:18 |
| Lor | http://pastebin.com/pi1Fw2YV | 14:18 |
| dickelbeck | Need help on a command line formulation. The built in help is not cutting it.... | 14:25 |
| dickelbeck | I want to get the diff between the latest rev in a branch and the previous version. How? | 14:26 |
| dickelbeck | A single file. | 14:26 |
| Lor | Previous version of the file or previous revision of the tree? | 14:27 |
| spiv | dickelbeck: bzr diff -c -1 FILE | 14:29 |
| spiv | Hmm, or perhaps bzr diff -r -1..-2 FILE depending on the direction you want. | 14:30 |
| dickelbeck | spiv: thanks, but that is outputting nothing. | 14:32 |
| dickelbeck | is there a way to show the last changes, regardless when they occurred? | 14:32 |
| jelmer | Lor: the first one seems like it could be in bzrlib somewhere | 14:33 |
| jelmer | Lor: the second one doesn't seem generic enough to me | 14:33 |
| dickelbeck | Lor: previous version of the file | 14:33 |
| Lor | jelmer, I would expect that something like the second one is needed by any plugin that creates metadata files. | 14:35 |
| Lor | Oops, default_path shouldn't be optional. | 14:36 |
| spiv | dickelbeck: oh, I see, I thought you meant the file as it was in the previous revision of the entire tree | 14:37 |
| jelmer | Lor: it encourages the use of hardcoded file ids though, and they are a bad idea | 14:38 |
| spiv | dickelbeck: I don't think we have a good shortcut for that :/ | 14:38 |
| jelmer | Lor: it should be possible for the user to create such files as well | 14:39 |
| Lor | Didn't we just talk about this? | 14:39 |
| jelmer | Lor: yes, but we concluded that constant file ids were bad right? | 14:39 |
| spiv | dickelbeck: although if I want to explore changes in old versions of a file I usually go straight to using something like 'bzr qannotate' | 14:39 |
| Lor | Not globally fixed but determined by the root id. | 14:39 |
| jelmer | Lor: file ids based somehow on the root id are a less bad idea | 14:39 |
| Lor | That's what's supposed to be given as an argument. | 14:39 |
| Lor | Sure, the above function could be given an "id template" which it would then mangle with the root id to create the actual file id of the created file. | 14:40 |
| jelmer | Lor: I'd rather see something more specific for that situation | 14:40 |
| jelmer | i.e. something that also makes sure .bzrmeta exists with a particular file id and takes a file-id postfix | 14:40 |
| Lor | Well, the function is underscored for a reason. :) | 14:41 |
| jelmer | Lor: it's also a bad idea to require that a path has a specific file id | 14:41 |
| spiv | Yeah, we should provide some facilities to help plugins use .bzrmeta | 14:41 |
| jelmer | Lor: it should be possible for the user to create these files manually | 14:41 |
| Lor | Not in this particular case. | 14:41 |
| Lor | The user isn't supposed to even see the file, much less alter it. | 14:41 |
| jelmer | always | 14:42 |
| jelmer | Lor: if the user isn't supposed to see the file it shouldn't be in .bzrmeta | 14:42 |
| Lor | Where, then? | 14:42 |
| Lor | I want the file to be versioned. | 14:42 |
| jelmer | .bzr/ | 14:42 |
| spiv | .bzr is the place for "No user serviceable parts inside" | 14:42 |
| Lor | Yes, but it isn't versioned. | 14:42 |
| jelmer | Lor: supporting this properly would require a format change | 14:43 |
| Lor | What should I do in the interim? | 14:44 |
| spiv | Hold your nose and use .bzrmeta, probably. | 14:44 |
| Lor | Currently the idea is that .bzrmeta/mtimes is recreated from scratch during commit. | 14:45 |
| Lor | Only the versions from the parent trees are read, not the one in the working tree. | 14:45 |
| jelmer | alternatively this sort of thing could supported by the luggage proposal when it is implemented | 14:48 |
| jelmer | *baggage | 14:48 |
| mwhudson | jam: you there? | 14:55 |
| jam | mwhudson: I'm here now | 14:57 |
| jam | downstairs in Pomegranate | 14:57 |
| mwhudson | jam: a good time to come down now? | 14:58 |
| jam | mwhudson: yeah, should be | 14:58 |
| mwhudson | cool | 14:58 |
| mwhudson | be there in a bit | 14:58 |
| dickelbeck | spiv: thanks, bye. | 15:00 |
| Lor | Is it recommended that even single-file plugins are implemented as myplugin/__init__.py instead of myplugin.py? | 15:14 |
| spiv | Lor: I think so; it gives you a place to put a README etc, and also means .pyc files are out of the way | 15:18 |
| Lor | Okie. | 15:18 |
| Lor | Still, code sharing seems tricky. | 15:19 |
| Lor | Well, nested trees would in theory be the solution... | 15:19 |
| Lor | (For development, not for distribution) | 15:19 |
| jelmer | Lor: How much code is there to share though? | 15:21 |
| Lor | In my case, probably not much. | 15:21 |
| jelmer | Lor: Ideally code that's generic enough should be in bzrlib | 15:22 |
| Lor | You can't expect a plugin author's workflow to be contingent on bzrlib development. | 15:23 |
| Lor | But yes, ultimately code can of course migrate from plugins to bzrlib. | 15:23 |
| jelmer | Lor: It's hard to answer this without a concrete example | 15:24 |
| Lor | How come? | 15:24 |
| jelmer | Lor: As far as I know (and have experienced, I've written > 10 plugins) bzrlib provides sufficient functionality | 15:24 |
| jelmer | Lor: You can always copy code between plugins if nothing else is possible and I've done that on occasion | 15:25 |
| Lor | Yeah, I'd like to avoid that. | 15:25 |
| jelmer | Lor: Ultimately that code has all gone upstream | 15:25 |
| jelmer | Lor: I guess you could maintain a library with utility code that more than one plugin can use | 15:27 |
| Lor | Yes, but distribution of plugins would be difficult. | 15:27 |
| Lor | Well, this is not a very critical problem. | 15:28 |
| jelmer | Lor: this is a problem with all sorts of library code and packaging | 15:28 |
| Lor | Yeah. | 15:28 |
| jelmer | Lor: the solution is called apt :-) | 15:28 |
| Lor | I wouldn't mind if launchpad automatically generated deb packages for the plugins. | 15:29 |
| jelmer | Lor: it doesn't have enough information to do that | 15:29 |
| jelmer | Lor: it could be possible with some extra metadata I guess | 15:29 |
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| yurii | Hi anyone around who uses Bazaar on Snow Leopard? | 15:55 |
| dash | i do | 15:57 |
| yurii | Any way I can uninstall the bundle? The uninstaller doesn't work on Snow Leopard | 15:58 |
| mwhudson | jam: the session just got cancelled :) | 16:15 |
| mwhudson | back soon | 16:15 |
| spiv | vila: https://bugs.edge.launchpad.net/paramiko/+bug/579530 is the bug for that failure | 17:00 |
| ubottu | Launchpad bug 579530 in bzr "paramiko does not try all available address families" [Medium,Confirmed] | 17:00 |
| vila | spiv: thanks ! | 17:01 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| vila | poolie: PING (note the caps), have a look at https://code.edge.launchpad.net/~mbp/bzr/491763-transform-rename-failed/+merge/24474 ! And land it quickly :-) | 17:03 |
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| === beuno is now known as beuno-lunch | ||
| === Pilky_ is now known as Pilky | ||
| ciss_ | hi | 18:09 |
| bendj | How do I 'reset' a repo's history to start at a given commit? E.g., if I've got many months' of revisions tracked, but don't need/want anything kep anymore before a recent commit labelled "blah blah". | 18:09 |
| ciss_ | i was wondering if someone can suggest a tutorial or tool on how to create patches from a revision and applying them via ssh? | 18:10 |
| dash | bendj: create a new branch using 'bzr init' | 18:10 |
| dash | bendj: copy files into it | 18:10 |
| dash | bendj: add them, commit. | 18:10 |
| bendj | dash: a bit confused ... that seems like it'd work just fine to create a 'reset' repo starting with the _current_ state. But I just want to 'prune' the repo of info/data before a given, prior commit. I.e., I _do_ want to have/track all the revisions _cince_ that prior commt. Possible? | 18:14 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| dash | bendj: i guess the 'rebase' plugin is supposed to do this | 18:16 |
| bendj | dash aha ... looking | 18:16 |
| bendj | dash: bzr_rewrite looks to be the ticket (http://wiki.bazaar.canonical.com/Rewrite). Thanks! | 18:18 |
| dash | 'bzr memory_hole' | 18:19 |
| bendj | :-) | 18:22 |
| Lor | bendj, tailor can do that too | 18:22 |
| bendj | Lor another new one for me, thanks! | 18:25 |
| === beuno-lunch is now known as beuno | ||
| mathrick | jelmer: hi | 21:06 |
| mathrick | bzr-git doesn't want to download git repos when served URLs like http://common-lisp.net/project/parenscript/git/parenscript/ | 21:07 |
| mathrick | ie. that directory already contains what .git normally holds | 21:07 |
| mathrick | git itself has no problems with operating off that | 21:07 |
| GaryvdM | mathrick: Do you get a error. | 21:08 |
| mathrick | bzr: ERROR: Not a branch: "http://common-lisp.net/project/parenscript/git/parenscript/". | 21:08 |
| GaryvdM | mathrick: I think it is a known error due to a change in python. | 21:08 |
| mathrick | oh? | 21:09 |
| GaryvdM | mathrick: What OS an bzr-git version? | 21:09 |
| * GaryvdM looks for bug | 21:09 | |
| mathrick | lucid and, lemme see | 21:09 |
| mathrick | bzr-git 0.4.3 | 21:09 |
| mathrick | out of some debs | 21:09 |
| GaryvdM | mathrick: I was think about Bug 556968, but that gives an error message. | 21:11 |
| ubottu | Launchpad bug 556968 in bzr-git "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository (needs upstream cherrypick/backport)" [Critical,Confirmed] https://launchpad.net/bugs/556968 | 21:11 |
| GaryvdM | mathrick: But that affects your version. | 21:11 |
| mathrick | GaryvdM: for me it seems likely that bzr-git is merely not expecting the git repo to be at the top level and not under .git | 21:12 |
| mathrick | it's too orderly to be that error :) | 21:12 |
| GaryvdM | mathrick: Ok - best look for Jelmer then. | 21:12 |
| ciss_ | is there a convenient way to remove all files from versioning that are matched by the patterns in .bzrignore? | 21:13 |
| * GaryvdM looks arround the lobby at uds for Jelmer, no, he is not here - sorry | 21:13 | |
| ciss_ | or are those automatically removed on the next commit? | 21:14 |
| mathrick | GaryvdM: ok, thanks | 21:15 |
| Lor | .bzrignore only applies to unknown files | 21:20 |
| Lor | As is good and proper. | 21:20 |
| Lor | I'm not sure that .bzrignore really belongs in the inventory. | 21:22 |
| Lor | It's just a user interface configuration, and no other configuration information is versioned. | 21:22 |
| ciss_ | Lor, usually my .bzrignore file needs some tweaking until i get all the rules right, putting several unwanted files into versioning in the process. i was wondering how to get them out of versioning without removing each pattern match one by one | 21:23 |
| Lor | Ordinary shell expansion ought to help a lot. | 21:25 |
| Lor | But really, you have been quite careless if you have added unwanted files and committed before checking what exactly is going to get in. | 21:26 |
| ciss_ | checking 11K files is a little time consuming | 21:26 |
| ciss_ | anyway, thanks for the hint | 21:26 |
| Lor | It's probably pretty simple to write a plugin to remove all files that match the ignore rules. | 21:27 |
| Kobaz | how do i undo a merge... i deleted new files, and revered modified files, but bzr st is still reporting a pending merge | 21:43 |
| Kobaz | i guess i can commit and then uncommit | 21:44 |
| beuno | Kobaz, --forget-merges I think | 21:44 |
| beuno | revert --forget-merges that is | 21:44 |
| beuno | I do think, though | 21:45 |
| Kobaz | nifty | 21:45 |
| Kobaz | that worked | 21:45 |
| beuno | that plain "bzr revert" should leave everything in a default state again | 21:45 |
| Kobaz | is there a changelog for the new stuff in 2.1.1 | 21:45 |
| Kobaz | i'm still on 1.18 | 21:46 |
| beuno | that's super old! | 21:46 |
| Kobaz | heh | 21:46 |
| Kobaz | but it works | 21:46 |
| beuno | 2.x has the new format | 21:46 |
| beuno | 2a | 21:46 |
| Kobaz | i upgraded to 1.20 at one point, and it kind of broke everything | 21:46 |
| beuno | which is a trillion times faster | 21:46 |
| Kobaz | so i stayed with 1.18 | 21:46 |
| Kobaz | mmm, it does seem faster | 21:57 |
| Kobaz | playing with a copy of my repo with 2.1.1 | 21:57 |
| kojiro | argh | 22:15 |
| bendj | my bzr is working ok. just installed bzr-git/dulwich. when i try to branch a git repo, i get an 'internal error' -> http://pastebin.com/kd2BsmDa | 23:35 |
| bendj | is it my bad, or a prob with bzr or bzr-git? | 23:35 |
| Peng_ | Prob'ly not your fault. | 23:43 |
| jelmer | bendj: bzr just changed its api and that broke bzr-git | 23:44 |
| jelmer | if you use a bzr from a couple of days back it should work ok | 23:45 |
| bendj | jelmer: Sounds like it's "known" ... still needs reporting? I've not (yet) found a bug abt it ... | 23:46 |
| jbowtie | jelmer: Any details on this API change? I've a got a foreign VCS plugin I might be releasing soon (waiting for approval from lawyers) | 23:48 |
| jelmer | jbowtie: basically lock_write / lock_read need to return an object with a unlock method now | 23:49 |
| jelmer | bendj: I don't think it's reported yet | 23:50 |
| jelmer | jbowtie: just curious, what foreign VCS does this plugin add support for or can you not say yet? | 23:51 |
| bendj | jelmer: offhand, know which revision triggered it? i've dropped back to r5218, from 5/7 -- same problem | 23:54 |
| Lor | Is it guaranteed that a merge with an ancestor will have no conflicts? | 23:54 |
| Peng_ | Look for "lock" in the log? | 23:54 |
| jelmer | Lor: I think so, it would be a no-op | 23:54 |
| jelmer | bendj: less than 10 revisions on mainline back | 23:55 |
| Lor | No, it creates a new revision. | 23:55 |
| Lor | Which is good, because I need that feature. | 23:55 |
| jelmer | Lor: merge never creates a new revision | 23:55 |
| Lor | I mean, it creates changes. | 23:56 |
| bendj | Peng_: sure, i did ... last 'lock' @ r5223 | 23:56 |
| Lor | And after the merge a commit won't complain that there are no changes to commit. | 23:56 |
| Peng_ | Lor: Not if you merge an ancestor, since it's a no-op. It does nothing whatsoever. | 23:57 |
| Lor | I mean, I merge the head _into_ the ancestor. | 23:57 |
| Peng_ | Oh. | 23:57 |
| Peng_ | Lor: in that case you could pull. | 23:57 |
| Lor | No, I want a merge. | 23:57 |
| Lor | It seems to work just right, I just want to know if there is some obscure corner case that could create conflicts. | 23:58 |
| jelmer | Lor: you're merging a single revision, not a range or something? | 23:58 |
| Lor | A range. | 23:58 |
| Lor | The idea is to make a bunch of revisions look like a single merge, so there will only be a single log entry shown by default. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!