| === kiko is now known as kiko-zzz | ||
| igc | bbiab | 01:37 |
|---|---|---|
| Verterok | moin | 02:21 |
| * igc lunch | 02:21 | |
| warnk | running 1.1.0 - is bzr's bugtracker feature supposed to be storing bug metadata or running some sort of post to the bugtracker url? i see a blueprint for bug metadata, docs sound like everything is implemented though | 03:06 |
| spiv | warnk: have you seen http://doc.bazaar-vcs.org/bzr.1.1/en/user-guide/index.html#integrating-bazaar-with-bug-trackers ? | 03:08 |
| spiv | warnk: basically, bzr gives you a standard way to mark a revision as fixing a bug, but it doesn't automatically try to interact with a bug tracker | 03:09 |
| warnk | i did see that, on second looking though, just saw mention of installing a hook | 03:10 |
| spiv | warnk: you could setup a cron job or bzr hook to automatically notice those revisions, and update your bug tracker, but there's nothing "out-of-the-box" you can use to do that. | 03:10 |
| spiv | e.g. you'd need to write the hook yourself. | 03:11 |
| warnk | spiv: i see now, section on bug tracker settings made it seem that http posts, w/e were part of the commit process | 03:12 |
| warnk | yeah, looking into hooks now | 03:12 |
| warnk | metadata on bugfixes isn't currently logged locally, is it? | 03:14 |
| spiv | "bzr log" doesn't report it, no. | 03:15 |
| spiv | It should | 03:15 |
| spiv | (I think there's a patch to the bzr-gtk plugin to make it show it, though) | 03:16 |
| warnk | a hook to use --fixes probably is too much, a little regex magic could make a really lame post-commit bug tracker though. interesting | 03:25 |
| * igc heading off early today | 03:39 | |
| igc | till tomorrow all | 03:40 |
| poolie | igc, have a good holiday | 03:40 |
| igc | thanks | 03:40 |
| === abentle1 is now known as abentley | ||
| lostylost | Could someone help me with this error? bzr: ERROR: Unable to delete transform temporary directory D:/invoice/trunk/.bzr/checkout/pending-deletion. Please examine D:/invoice/trunk/.bzr/checkout/pending-deletion to see if it contains any files you wish to keep, and delete it when you are done. | 07:56 |
| lostylost | I am loathe to mess around as I am new to bzr and even version control | 07:56 |
| lostylost | now there is a lock on my bzr repo as well | 07:56 |
| Peng | Well, you can use "bzr break-lock" for that. That's not dangerous. | 07:57 |
| lostylost | cheers | 07:57 |
| Peng | (As long as you're sure no other process or user has it open..) | 07:57 |
| lostylost | It happened after running bzr update after a local commit | 07:57 |
| Peng | I've never heard of the pending-deletion thing, so I can't help. | 07:57 |
| lostylost | no worries | 07:58 |
| lostylost | it's been happening every time I uses local commits | 07:58 |
| lostylost | instead of commiting to the main repo every time | 07:58 |
| lostylost | not exactly what's on the lid | 07:59 |
| Peng | If you use local commits a lot, perhaps you should use a branch. | 07:59 |
| lostylost | I did | 07:59 |
| lostylost | "bzr branch location" yeah? | 07:59 |
| Peng | yes. | 07:59 |
| lostylost | I went a bit trigger happy with the bzr mv at one stage | 08:00 |
| lostylost | maybe that's the problem | 08:00 |
| lostylost | I had to recover a missing revision after deleting those files with the HEADS plugin | 08:00 |
| Peng | I'd be very surprised if that was the problem. | 08:00 |
| lostylost | I would hope so really that it wasn't that | 08:00 |
| Peng | lostylost: Err? I don't know about the HEADS plugin. | 08:00 |
| lostylost | I don't really know much either | 08:01 |
| lostylost | but I used it to recover the dead HEAD revision | 08:01 |
| lostylost | my last local commit | 08:01 |
| Peng | Recovering a revision? What happened to it? | 08:01 |
| lostylost | well I messed around deleting those temporary files | 08:02 |
| lostylost | thinking that it would just be in my repo and I could | 08:02 |
| lostylost | bzr revert | 08:02 |
| lostylost | but the revision disappeared from my log | 08:02 |
| lostylost | one of the bzr developers was around on this channel and he referred me to the HEADS plugin | 08:03 |
| lostylost | Now the same problem has occured but I am loathe to mess around with it too much | 08:03 |
| lostylost | not really knowing what I am doing | 08:04 |
| === bzlm^away is now known as bzlm | ||
| * bzlm e i huset | 08:15 | |
| ubotu | New bug: #185574 in bzr-svn "Checkout from WebDAV server fails" [Undecided,New] https://launchpad.net/bugs/185574 | 10:40 |
| === kiko-zzz is now known as kiko | ||
| === lifeless_ is now known as lifeless | ||
| jrydberg__ | jelmer: there? | 11:45 |
| ubotu | New bug: #185591 in bzr-eclipse "Files moved by refactoring not moved in bzr" [Undecided,New] https://launchpad.net/bugs/185591 | 11:46 |
| jelmer | jrydberg__: hi | 12:27 |
| jrydberg__ | jelmer: how do you suggest i work against a upstream svn repo? | 12:41 |
| jrydberg__ | jelmer: i keep a bzr-version of the trunk in the repo, and merge everything into that when i want to push upstream? | 12:42 |
| jelmer | jrydberg__: yeah, that would be one way. Another would be to use a checkout | 12:42 |
| jrydberg__ | i want to use bzr's merge tracking | 12:43 |
| jrydberg__ | jelmer: bzr: ERROR: Repository KnitPackRepository('file:///exports/lithium/jrydberg/repository/.bzr/repository/') is not compatible with repository SvnRepository('svn://picnic1/sw') | 13:03 |
| jrydberg__ | a common error? | 13:03 |
| jelmer | jrydberg__: See the FAQ | 13:03 |
| jelmer | jrydberg__: Basically, you need a rich-root(-pack) repo | 13:03 |
| jrydberg__ | jelmer: you said i could use a checkout. what would that gain me compared to using subversion? | 13:08 |
| jelmer | jrydberg__: the ability to "bzr merge" from bzr branches | 13:22 |
| ubotu | New bug: #128496 in subversion "Unable to open native working tree with non-ascii filenames" [Undecided,New] https://launchpad.net/bugs/128496 | 13:56 |
| === mrevell is now known as mrevell-coffee | ||
| === mrevell-coffee is now known as mrevell | ||
| === beuno_ is now known as beuno | ||
| === kiko is now known as kiko-fud | ||
| === kiko-fud is now known as kiko | ||
| brink__ | Anyone know the tradeoffs between rich-root and pack-0.92? | 17:35 |
| dato | brink__: the proper question would be "between knits and pack-0.92" or "between rich-root-pack and pack-0.92" | 17:42 |
| dato | brink__: because rich-root is knits+rich-root | 17:42 |
| brink__ | Hmm. Bzr help upgrade lists them as pack-0.92 and rich-root. If the tool uses that vocabulary then it's a valid question. No? | 17:44 |
| jw2328 | brink__, rich-root uses knits, which are a data format that makes bzr slower than with packs. | 18:10 |
| jw2328 | however packs require clients to have at least 0.92 | 18:11 |
| jw2328 | also, rich root stores information that packs-0.92 does not. It is planned to transition to store this information by default at some point. | 18:12 |
| jw2328 | --rich-root-pack is the equivalent for packs. | 18:12 |
| jw2328 | I would recommend the latter if clients that access the repo are going to be recent versions (1.0 or even 1.1 I think) | 18:13 |
| jw2328 | if you need to support clients less than 0.92 then use a knit based format. | 18:13 |
| brink__ | Thanks. I noticed that rich-root-pack is labeled as experimental on my current version of bazaar (1.0rc1 on Ubuntu). | 18:14 |
| jw2328 | I would definitely recommend using packs if you can. | 18:14 |
| mtaylor_ | rich-root-pack good | 18:14 |
| brink__ | Is rich-root-pack safe? | 18:15 |
| jw2328 | well, don't let it get hold of any sharp objects. | 18:16 |
| === jw2328 is now known as james_w | ||
| brink__ | Most code is pretty dull. | 18:16 |
| james_w | brink__, if you hang on a minute I'll give you a sensible answer | 18:18 |
| brink__ | Take your time. I'm here. | 18:18 |
| james_w | brink__, someone far more knowledgeable than me says that rich-root-pack in itself is safe, however upgrading from non-rich root is a little flaky. | 18:25 |
| james_w | So, if you are starting a new project then start with rich-root-pack. If not then hang on until the converter is up to scratch. | 18:25 |
| brink__ | sounds like good advice. | 18:26 |
| Bloguero__Connor | .motd | 18:34 |
| Bloguero__Connor | hello, the program is called bzr or baz? | 18:35 |
| Bloguero__Connor | downloaded from apt-get install bazaar (using Ubuntu), I get it as baz. Is it OK? | 18:35 |
| beuno | Bloguero__Connor, bzr | 18:35 |
| beuno | baz is old/abandoned | 18:36 |
| james_w | Bloguero__Connor, apt-get install bzr | 18:37 |
| Bloguero__Connor | beuno: Why do I get baz -V: Bazaar version 1.4.2 (thelove@canonical.com/dists--bazaar--1.4[bazaar--devo.cfg]) | 18:37 |
| Bloguero__Connor | OK | 18:37 |
| lifeless | Bloguero__Connor: you've installed an old version of the software | 18:37 |
| beuno | Bloguero__Connor, because it's called bazaar too | 18:37 |
| lifeless | Bloguero__Connor: the new version is called 'bzr' - 'apt-get install bzr' | 18:38 |
| Bloguero__Connor | OK, let me try again | 18:38 |
| Bloguero__Connor | Yes, now I installed sbassi@JeOS1:~$ bzr version | 18:40 |
| Bloguero__Connor | Bazaar (bzr) 0.90.0 | 18:40 |
| beuno | Bloguero__Connor, I'd recommend you install the latest version from PPA: https://edge.launchpad.net/~bzr/+archive | 18:41 |
| beuno | 1.1 has a _lot_ of improvements and storage format change | 18:41 |
| beuno | so it's the safest bet | 18:41 |
| Bloguero__Connor | IMHO, when you do "apt-get install bazar", you should get a warning that this is an old version and that the current is bzr. Just an opinion. | 18:42 |
| beuno | Bloguero__Connor, well, I think baz is getting removed from Debian | 18:42 |
| Bloguero__Connor | beuno: OK, thank you!!!! | 18:43 |
| beuno | lifeless, how about in Ubuntu, wouldn't it make sense to remove it too? | 18:43 |
| lifeless | beuno: yes; bazaar should be a migration package depending on bzr, baz | 18:45 |
| dato | w00t | 18:45 |
| dato | I built bzr 1.1 for sarge, because one user requested it | 18:45 |
| dato | what a PITA, though | 18:45 |
| lifeless | tchau | 18:45 |
| Bloguero__Connor | dato: where is it located? | 18:46 |
| dato | Bloguero__Connor: backports.org in a couple minutes | 18:46 |
| dato | Bloguero__Connor: (the source, a couple minutes; binaries for i386 and amd64 should follow in a while) | 18:47 |
| Bloguero__Connor | dato: binaries for 386 is enought for me :) | 18:47 |
| beuno | lifeless, so I should send a mail to the list and see who/how/when? might be good to have it done before Hardy releases | 18:48 |
| dato | should ideally be done in debian as well | 18:48 |
| beuno | dato, I think ASCIIGirl filed for removal already, we talked about it the other day as the package was orphaned | 18:49 |
| james_w | beuno: it has been discussed with the Debian maintainer, so a bug with patch in Debian would be the best way of doing it. | 18:50 |
| dato | beuno: I don't see it orphaned | 18:50 |
| james_w | beuno, baz was orphaned? | 18:50 |
| dato | bazaar-doc is orphaned | 18:50 |
| dato | not bazaar | 18:50 |
| TeTeT | is there a nice way to only merge certain files of a branch with another? e.g. all .xml and .png files, but not Makefile, .xsl and such? | 18:50 |
| james_w | TeTeT, bzr merge ../branch/file | 18:51 |
| beuno | dato, aaah, she might of missed that -doc bit | 18:51 |
| TeTeT | james_w: for all files? | 18:51 |
| james_w | TeTeT, oh, no, hang on. | 18:51 |
| beuno | james_w, what dato said :D | 18:51 |
| james_w | TeTeT, yeah, I think so. shell expansion should help. | 18:53 |
| james_w | TeTeT, try it. What's the worst that can happen? | 18:53 |
| TeTeT | rm -rf, bzr branch | 18:53 |
| TeTeT | or even bzr revert | 18:54 |
| beuno | dato, seems she didn't finish bazaar-doc either, so I'll mail the list for Ubuntu and Debian | 18:54 |
| brink__ | How come apt-get upgrade only gets me up to 1.0.0.candidate.1? Aren't we up to version 1.1? | 18:54 |
| Bloguero__Connor | good bye! | 18:56 |
| james_w | brink__, what repos are you using for that/ | 18:56 |
| brink__ | Not the repos. bzr --version tells me it's 1.0.0.candidate.1. | 18:57 |
| TeTeT | james_w: thanks, http://paste.ubuntu-nl.org/53357/ did the job | 18:58 |
| james_w | brink__, yeah, I mean where are you expecting to get the new version from? | 18:58 |
| james_w | (Ubuntu, Debian, bazaar-vcs.org, PPA) | 18:58 |
| brink__ | Ubuntu | 18:58 |
| james_w | hardy? | 18:58 |
| james_w | TeTeT, great. Glad to know it works. | 18:59 |
| luks | TeTeT: ouch, wouldn't it be better to merge it all and then revert files you don't want to get merged? | 18:59 |
| dato | some ubuntu guy /queried me the other day, and it seemed he'd work into getting 1.1 into hardy | 18:59 |
| james_w | luks, no, not if you want the rest of the changes later. | 18:59 |
| TeTeT | luks: might be another good idea | 18:59 |
| luks | bzr revert --forget-merges | 18:59 |
| james_w | dato, I think the request has been filed, so next time an archive admin processes the queue it should sync and build. | 19:00 |
| james_w | luks, true. | 19:00 |
| TeTeT | the loops takes a while for 400+ pngs ... | 19:00 |
| luks | this just doesn't seem right, because it must have produced a lot of unnecessary commits | 19:00 |
| dato | ok. he was worring about sid only having the rc1, and I told him there hadn't been any code changes | 19:00 |
| TeTeT | luks: yes, it produced around 20 | 19:01 |
| james_w | luks, TeTeT, can you just commit once at the end? Perhaps you will have to add --force to the merge. | 19:01 |
| luks | yes, with --force | 19:01 |
| TeTeT | james_w: haven't tried that | 19:01 |
| brink__ | I'm also trying to install it on tiger PPC without much luck. Macports says the following dependencies failed to build:-bz2 python25 py25-crypto py25-hashlib py25-paramiko py25-zlib | 19:01 |
| james_w | bzr ls --modified | grep -v png\$ | xargs bzr revert; bzr revert --forget-merges; bzr commit | 19:02 |
| TeTeT | but honestly I don't mind having a commit for each individual file | 19:02 |
| === mw is now known as mw|food | ||
| james_w | I'm done for the day. Bye all. | 19:05 |
| === mw|food is now known as mw | ||
| acuster | hey all, how do I get a diff between an upstream svn server and my current bzr? | 19:57 |
| acuster | I should have a two line change locally compared to the server | 19:58 |
| acuster | I'd like to know what's going to happen if I to a bzr push against the remote server | 19:58 |
| jelmer | acuster: bzr diff -rbranch:svn-url | 19:58 |
| acuster | thanks | 19:58 |
| acuster | one other point of confusion, I did one bzr branch from the svn server to a branch locally, and then branched that into a working directory | 19:59 |
| acuster | why does bzr push from the working directory not push to the other local branch from which it came? | 20:00 |
| acuster | it goes directly against the remote svn server | 20:00 |
| acuster | i'm clearly missing a piece of the puzzle | 20:00 |
| acuster | :-) | 20:00 |
| dato | push from the working directory should have no default push location | 20:00 |
| dato | so most likely you specified the svn server once? | 20:01 |
| acuster | so can i have a push in the working directory go to the 'master' branch ? (or, what command do I read about to reset the push location?) | 20:02 |
| dato | to reset, bzr push --remember someotherlocation | 20:03 |
| beuno | acuster, you can also switch between where you push all you want, push once to the the local bzr branch, once to the svn, you can work as you like. --remember will overwrite the default location, as dato mentioned | 20:04 |
| acuster | thank you all. /me runs off to learn some more and see what happens | 20:05 |
| === kiko is now known as kiko-afk | ||
| brink__ | Is it ok to store unrelated branches in a shared repository? | 20:33 |
| brink__ | Also, can you delete branches within a shared repository? | 20:34 |
| radix | brink__: yes and yes | 20:37 |
| brink__ | And you delete them simply with rm -rf ? | 20:38 |
| radix | brink__: yep. | 20:38 |
| brink__ | Nice. | 20:38 |
| radix | brink__: the revision data will stay around in the repository, so you won't reclaim much space | 20:38 |
| brink__ | That's ok. It isn't the space that bothers me. Just the clutter. | 20:39 |
| radix | maybe some day there will be some garbage collection that cleans it up | 20:39 |
| brink__ | I'm debating whether I should just have a directory with branches or a shared repo with branches. All the branches are currently unrelated. | 20:40 |
| luks | it won't bring you any benefit, and might slow some things down | 20:41 |
| luks | but not much | 20:41 |
| brink__ | Any advantages for multiple users? | 20:41 |
| luks | disadvantages | 20:42 |
| luks | if two users want to commit to the same repository at the same time, they have to wait | 20:42 |
| luks | it really makes sense to use shared repositories only for branches that share some revisions | 20:43 |
| brink__ | Sounds like a shared repo is a good thing for efficient storage of tags and dead branches, but not much else. | 20:43 |
| luks | well, it's very useful if you have 20k revisions and a lot of feature branches | 20:44 |
| luks | but if you have separate projects, it's better to have separate repositories for them | 20:44 |
| brink__ | Thanks. | 20:45 |
| brink__ | What's the best way to set permissions? Is it 2770 or just 770? | 20:46 |
| Debolaz | Are anyone here convertees from git or hg? I'm writing up a comparison of the various scms, and I was curious what made people switch. | 20:53 |
| mw | not really, but the fact that i have to use them for some projects i'm involved with makes me appreciate bzr quite a bit | 20:59 |
| brink__ | I used hg for a bit. I switched because I rename things on occasion and I thing bazaar handles it better. Also, I found it easy to plugin diff tools. | 21:03 |
| brink__ | I think the diff plugin should be standard actually, rather than a plugin. It's too useful to be a plugin. | 21:04 |
| === Debolaz2 is now known as Debolaz | ||
| pickscrape | Quick question. I'm currently evaluating bzr as a svn replacement, and am importing a large (41k) revision repository. | 21:41 |
| pickscrape | I'm already seeing the effects of the memory leak in the python bindings that is fixed in svn 1.5 | 21:42 |
| pickscrape | My question is, if the memory consumption gets too high, can I kill the process and get it to continue somehow? | 21:42 |
| jelmer | pickscrape: yes, as long as you use a shared repository | 21:46 |
| pickscrape | At my end? Or at the server end. | 21:47 |
| pickscrape | (sorry, I've started looking at bzr *today* so I'm new to the terminology too). | 21:48 |
| bob2 | on your end (bzr init-repo --rich-root repo ; bzr branch svn:/// repo/branchname) | 21:50 |
| pickscrape | Ah, so I need to init the repo first. I was just issuing the branhc command and having it create the repo for me. | 21:51 |
| pickscrape | Thanks, I'll rectify that right away... :) | 21:51 |
| fullermd | jelmer: Would it work too if you did an 'init ; pull' dance instead of 'branch'? | 21:51 |
| jelmer | yeah, that would work as well | 21:51 |
| jelmer | it would be nice if we could get bzr branch do create something that is resumable | 21:52 |
| bob2 | I'd've thought branch would be resumable with pull | 21:52 |
| pickscrape | Am I able to do an entire repository, or do I need to just branch one subversion 'branch'? | 21:53 |
| bob2 | bzr svn-import | 21:55 |
| pickscrape | Ah, thanks again | 21:57 |
| asabil | pickscrape: the bzr-svn memory leak got fixed in ubuntu I think | 21:57 |
| pickscrape | I'm using gentoo | 21:57 |
| pickscrape | Though I am using the bzr overlay | 21:57 |
| asabil | pickscrape: I am not sure your process will survive with a 41K revision and an unpatched memory leak | 21:57 |
| jelmer | asabil: Not yet, there is a patch but no new package has been uploaded yet | 21:57 |
| asabil | oh ok jelmer | 21:58 |
| asabil | pickscrape: maybe you want to try to apply the patch first ? | 21:58 |
| pickscrape | asabil: that's why I'm hoping I can stop and restart it periodically | 21:58 |
| asabil | ok I see :) good luck | 21:58 |
| pickscrape | The gentoo overlay laready applies a couple of patches to subversion. I won't why it doesn't apply this one too. | 21:58 |
| pickscrape | s/won't/wonder/ | 21:59 |
| pickscrape | BTW I'm very impressed with the site. The workflows page in particular is something that I think other systems' sites are lacking | 22:00 |
| pickscrape | The next step would be examples of how to set each of those workflows up. That would be extremely useful to newcomers such as myself :) | 22:01 |
| asabil | jelmer: concerning the bug display you added to bzr-gtk | 22:02 |
| asabil | wouldn't it be nice to have something like the current tags display in the branch graph ? | 22:03 |
| jelmer | for fixed bugs you mean? | 22:04 |
| jelmer | yeah | 22:04 |
| asabil | yep | 22:05 |
| AfC | jelmer: there was a fellow in here the other day reporting about using bzr-svn to clone KDE. Most of his problem (once he got over the lack of UI feedback at certain stages due to the monster size of what he was importing) was about disk space; | 22:10 |
| jelmer | AfC: Yeah, I plan on getting rid of that eventually | 22:10 |
| AfC | jelmer: specifically "why is it taking so much space on my home partition"; most everyone here was like "hey don't worry about it" but he was like "no, it's a GB, and it matters" | 22:10 |
| pickscrape | The svk depot for the repo I'm trying to clone is 7.4G. It will be interesting to see how big it is when cloned by bzr. | 22:11 |
| AfC | which was an interesting angle; he had the repo going somewhere else, but bzr-svn's (sqlite?) database of bzr id to svn id (sic?) mappings is (apparently?) in ~/.bazaar/whatevger | 22:11 |
| AfC | and that was causing him concern. | 22:12 |
| AfC | jelmer: I thought I'd raise it with you to ask if possible & suggest if it is | 22:12 |
| antares | Hello! | 22:12 |
| AfC | jelmer: that perhaps this database (sic) could be stored in the repository rather than in ~/.bazaar | 22:12 |
| AfC | (ie something custom in .bzr/repository/) | 22:13 |
| AfC | jelmer: Just a thought. That's it. | 22:13 |
| jelmer | AfC: The problem then is what to do when somebody runs "bzr log svn://foobar/" | 22:13 |
| AfC | jelmer: interesting. | 22:13 |
| AfC | jelmer: (offer them a free lobotomy?) | 22:13 |
| pickscrape | Perhaps a simple pointer in ~/.bazaar ? | 22:14 |
| jelmer | AfC: Also, that means somebody could be using a lot of diskspace if they don't use repositories but multiple branches | 22:14 |
| jelmer | and wasting a lot of time creating that cache every time | 22:14 |
| AfC | jelmer: yeah, well. That's what hard links are for :) | 22:14 |
| AfC | jelmer: (sometimes I think we offer too much flexibility in making share repository optional. So cool, but alas) | 22:15 |
| pickscrape | svn-import is actually doing a lot better with memory than branch was. | 22:18 |
| jelmer | pickscrape: probably because the cache is already partially filled | 22:19 |
| jelmer | pickscrape: it uses the same python subversion bindings so it'll have the same memory leak | 22:19 |
| pickscrape | ah right | 22:21 |
| pickscrape | Is there an interactive commit tool for bazaar that lets you choose individual hunks (a la git-gui)? | 22:22 |
| jelmer | "bzr gcommit" (from bzr-gtk) allows selecting individual files | 22:24 |
| pickscrape | Yes, I've found that. It would be nice if it could do it on a per-hunk basis too. | 22:25 |
| acuster | wohoo! My first commit from bzr into our svn! | 22:29 |
| acuster | thanks jelmer for all the hard work! | 22:29 |
| acuster | and to all the bzr folk | 22:29 |
| jelmer | pickscrape: Feel free to file a bug report :-) | 22:31 |
| jelmer | acuster: glad you like it | 22:31 |
| acuster | :-) | 22:31 |
| pickscrape | jelmer: will do :) | 22:32 |
| spiv | jelmer: perhaps a compromise might be to emit a message the when a cache for a new SVN repo is created? e.g. "Initialising SVN revision mapping cache in ~/.bazaar/subversion/foo..." | 22:34 |
| jelmer | spiv: Yeah, that makes sense | 22:34 |
| spiv | Just doing it when a cache is created probably isn't too chatty. | 22:34 |
| spiv | And then for the rest of the time you'll get that nice, silent "Just Works" behaviour ;) | 22:35 |
| acuster | well that turned into a minor disaster | 22:47 |
| dato | disaster? | 22:48 |
| fullermd | I call that 'normal' ;) | 22:48 |
| acuster | a two line change turned into a three part push that hit about a hundred files | 22:49 |
| * acuster is back to svn merging the reverse diff | 22:49 | |
| acuster | I'm stressing bzr a bit beyond what it has seen before I think. | 22:50 |
| ubotu | New bug: #185764 in bzr "Add support for defining the code to commit at the hunk level in gcommit" [Undecided,New] https://launchpad.net/bugs/185764 | 22:51 |
| jelmer | pickscrape: btw, it is possible to use bzr shelve to temporarily remove bits from the working tree that you don;t want to commit | 23:00 |
| pickscrape | Individual parts of files? | 23:02 |
| fullermd | diff hunks | 23:02 |
| pickscrape | Cool. | 23:02 |
| poolie | jam, standup tim | 23:02 |
| * pickscrape marks down bzr shelve as something else to look at | 23:03 | |
| fullermd | Hmm. Is bzr.dev supposed to work against 1.1 SS's again? | 23:04 |
| acuster | is dir_conflicts.prej a bzr generated file? | 23:09 |
| bob2 | "prej" doesn't occur in the bzr source | 23:10 |
| acuster | thanks, maybe it's svn then | 23:14 |
| ubotu | New bug: #185772 in bzr "Ability to set two authors for a commit" [Undecided,New] https://launchpad.net/bugs/185772 | 23:16 |
| === jamesh__ is now known as jamesh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!