=== abentley1 is now known as abentley [00:59] switch hurts with object files [00:59] perhaps switch should take into account ignored files (like .o) [01:24] thumper: ack [01:24] thumper: bites me all the freaking time [01:44] lifeless: we should come up with a plan [02:09] thumper: needs amerge conflict handler/resolver [02:10] lifeless: debian/changelog conflict handler/resolver!!!! :) [02:13] mtaylor: doneish [02:14] mtaylor: see the recently added merge hook [02:15] lifeless: w00t [02:18] I cant add files in a directory has 2.0 changed [02:18] are .cs files ignored by default? [02:21] hmm [02:31] keithy: No, .cs files aren't ignored by default. What are you trying to do and what is bzr doing instead? [02:32] ok.. [02:32] I have a directory called updates [02:32] and when I do [02:32] bzr add updates/ [02:33] and bzr status reports unkown: [02:34] so even basic stuff is defeating me [02:34] Well, it works here. [02:35] Can you pastebin the full terminal output of what you're doing and what bzr says in reply? [02:35] k [02:35] do you have a pastebin? [02:36] * igc lunch [02:38] keithy pasted "Bzr" at http://paste.lisp.org/display/93674 [02:38] paste.ubuntu.com works. [02:40] keithy: Have you actually run “bzr add updates/”? I don't see that in your terminal log, and that works for me. [02:40] yes [02:40] it does nothing [02:41] and there are 300 files in there that I expected to be added [02:42] I guess another option would be “bzr add updates/*”, but I'm not sure why it hasn't worked already. [02:43] no that didnt work weither [02:45] ok I started again [02:45] it worked this time [02:45] Heh. [02:45] I wonder what was wrong, though. [02:56] i pulled from another repo into mine and got http://sortedbits.ath.cx/bzr/nitrobot.bzr is permanently redirected to http://sortedbits.ath.cx/bzr/nitrobot.bzr/ [02:57] is that a problem? [02:57] and should i be using merge instead? [02:57] Not a problem [02:57] i'm trying to bring in someone's commit from his tree [02:57] into the main tree [02:57] It's just saying you didn't have a trailing '/' [02:57] i did have a trailing / but ok [02:57] [oh] [02:58] but i suppose that's not a problem [02:58] no [02:58] is pull the correct function to use to bring commits from someone else's branch into the main branch? [03:00] merge doesn't do the job [03:00] my commit log looks like this if i do, 1, 2, 3, 4, 5, 6, 7, 1, 2, 3 ,4 ,5 ,6 ,7 ,8 [03:02] meoblast: merge is for combining lines of development, yes [03:02] mwhudson: so why does it duplicate commits 1 - 7? [03:03] meoblast: it doesn't usually... [03:03] mwhudson: ok, fixed [03:04] when merging, do modified files in the merge come up as "modified:" as well? [03:08] meoblast: yes [03:10] ok, thanks === timchen119 is now known as nasloc__ [03:51] lifeless: can i object mildly to bzrlib.tests monkeypatching traceback? [04:06] mwhudson: you can object to traceback being brokeb. === abentley1 is now known as abentley [09:08] * igc dinner === Leonidas1 is now known as Leonidas [11:36] hey, Im trying to make a new branch, but for some reasons it says I don't have pernissions for that [11:37] Ive done bzr init; bzr add; bzr push lp:~ddorda/gezer/po [11:38] $ bzr push lp:~ddorda/gezer/po [11:38] Permission denied (publickey). [11:38] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. === abentley1 is now known as abentley === mrevell is now known as mrevell-lunch [12:51] Hi. Is there any way to show swedish letters in bzr-explorer in windows. Or at least space character. As it is now there's a % sign and some number afterwards. [12:57] Anyone? [12:57] ahh! I made it [12:57] ok... [12:57] its taken me so long to get here I cant remember what my question was [12:57] oh yes [12:58] is there an automatic directory contents tracking feature yey [12:58] yet [12:58] so you can add a directory and all its contents [12:58] non-manually [12:58] bzr add-and-track-contents somedirectorywherepeopleputstuff [12:59] Why does bzr-explorer in win xp show %20 instead of a space character? [13:04] it looks like add doesnt have this option arg [13:06] keithy: err, using what tool? "bzr add directory" works for me... [13:06] I must be misunderstanding your question [13:06] bzr add --no-recurse directory for just the directory [13:09] but what if someone adds a file after you have done bzr add directory/ [13:09] it is not managed is it [13:11] No, and this is intentional === mrevell-lunch is now known as mrevell === gerard_1 is now known as gerard_ [14:21] hey guys. [14:21] just trying to add files to a repo on a webserver, so i can download the site through bzr. [14:22] i am on the ssh root [14:22] on the ssh shell as the website owners user, not root, sorry [14:22] i have a web/ dir and a bzrsrc diri i've made [14:22] i did bzr init on the bzrsrc [14:23] then i copy in all the files under web [14:23] then bzr add * [14:23] then i try to bzr ci it rolls through tons and eventually gets to a pdf, and hangs. [14:23] if anything in there is huge it may just be slow [14:23] i can ctrl+c outa the commit action, but of course i'm scared that'll ruin something. [14:24] it's only 5.4MB [14:24] just sitting there. [14:24] fishy [14:24] how can i debug this/ [14:24] ? [14:25] I'd consider strace-ing the process to see what it's doing [14:25] strace-ing? [14:25] assuming that server runs linux [14:26] from your description it sounds like you're doing something quite normal and the only reason I can think of for a hang would be disk io being slow for some reason [14:26] it's ubuntu dapper. [14:26] sorry, ubuntu hardy. [14:26] 8.04.3 [14:31] so how do i run this strace [14:31] ? [14:31] still sitting there for the last 4 minutes. [14:31] ahhhhh, finished!!!!!! crap [14:31] woah, splity [14:35] morning all [14:37] morning jam ! [14:37] * vila almost miss the message in the storm.... [14:38] s/miss/missed/ [14:38] Hi everyone. [14:38] I could use some help. [14:40] what do you need michaelis [14:41] If a have an old revision and update it with bzr update, then my local changes still remain intact and I have to bzr commit to update the working tree. But after running bzr update, is there a way to see what the differences are between my local tree and the tree on the server? [14:44] Maybe it works as a shell command but it most certainly doesn't work in bzr-explorer. [14:44] not sure if this will work but try doing "bzr diff 'Path-to-remote-branch'" [14:44] oh, bzr-explorer... um. just a sec. I'll check [14:45] There are possibilties to define aliases in bzr-explorer but how do I run them in the explorer? [14:48] * mzz wonders what RAOF is doing [14:49] michaelis: I"m not sure about either of those questions :( I'm sorry. I wish igc was up. [14:50] vila: do you know anything about bzr-explorer or know of anyone who does? michaelis has some advance usage questions. [14:51] rubbs: sry, my front-end is emacs :-/ === salgado is now known as salgado-lunch [14:52] michaelis: after an update, your working tree will be like the remote tree *plus* your local changes [14:52] np... just thought I'd ask. Better to ask and be wrong rather than not ask and loose out on an opertunity for help [14:52] michaelis: so doing 'bzr diff' will be enough [14:52] rubbs: you're welcome, I appreciate your efforts ! [14:53] gee this IRC storm is worse every minute [14:54] Wait a minute. [14:58] ubottu: behave please, that's not how a good bot stands in a channel, your programmer will be ashamed [14:58] lol [14:59] But the problem is that the diff button in the explorer doesn't show the difference between two versions. [14:59] But there are possibilities to define aliases. How do I run them in the explorer? [14:59] michaelis: no idea about bzr-explorer [15:00] michaelis: 'bzr diff' will compare your branch tip to your working tree content, there is no need to specify anything [15:01] michaelis: just after a 'bzr update' you branch tip is the last revision commit on the remote branch, so this seems to be exactly what you want [15:01] s/you branch/your branch/ [15:03] Thanks. I will try it out. [15:12] hi [15:12] sure its intendional, but its not the behaviour I need [15:12] maxb: [15:18] keithy: you may be interested in the --strict switch to commit, iirc [15:18] ? [15:18] hmm [15:19] I just want to tell people to do a commit [15:19] other tools are producing the files [15:19] tell them to do a commit when? [15:19] they work in their tools the tools product files [15:19] bzr isn't some background process that monitors your dir for new files [15:19] and at the end of the day they commit and or push [15:20] there are a couple of operations (like bzr st, bzr ci, etc) that look at the working tree and will notice any new files [15:20] well it has the notion of a directory [15:20] do you need to tell bzr which lines of a flie to commit? [15:20] bzr has directories as first class objects [15:20] did you actually look at the --strict switch to commit I just mentioned? [15:20] yes [15:21] ok [15:21] so the response form commit is to tell me to go and add files manually [15:21] it's probably not hard to add a commit-like command or another switch to commit that just has it add any unknown files before committing [15:21] would that actually do what you want? [15:21] I guess I want a [15:21] bzr add --auto blah/ [15:21] of course simply calling "bzr add; bzr commit" where you're currently running "bzr commit" would work too, in that case. [15:22] adding some extra metadata to tracked directories that tells bzr they should get this automagic behavior seems like a hassle [15:35] Hi again. [15:37] When I select a branch in the repository I in the bottom window of the explorer that the text "no parent location selected yet" is showing. What does this mean and how do I fix it? [15:38] repository I in = repository I see in === bigjools-afk is now known as bigjools [15:43] I'll come back tomorrow and ask the same question. Bye. === salgado-lunch is now known as salgado [16:03] ok, bzr crash on trying to check out a large repo, 3.1GB, probably due to backup files being included. [16:03] data files in forms of documents and in form of uploaded mp3'aac's and other audio files. etc [16:04] maybe i should cut them [16:05] mzz: hassle? it seems obvious to me [16:05] its hassle not having it [16:06] keithy: please don't enable it for me, I'd end up accidentally checking in backup files and having to uncommit them a countless number of times [16:07] k [16:07] np I wont [16:10] I'm surprised there isn't a bzr commit --add or somesuch [16:15] I use bzr add `bzr unknown` quite often [16:15] and sometimes bzr add `bzr unknown | grep -v no_not_that` [16:21] ooo interesting [16:23] keithy: typo, by the way. the command is unknowns, with an s on the end :) === herb__ is now known as herb [16:35] aghghh [16:35] getting bzr: ERROR: zlib.error: Error -3 while decompressing: incorrect data check === beuno is now known as beuno-lunch [17:12] vila: today is the day to cut 2.0.4 and 2.1.0rc1, do you know of anything pending that needs looking at? [17:13] jam: plain and simple: no, I'm pretty sure we landed everything timely [17:15] jam: if you need a nudge to land your autopack fix in rc1 I can do that for you :) [17:15] vila: its in pqm now [17:15] the ignore exceptions is something I'd like to land [17:16] jam: AIUI you're waiting for some feedback on perfs [17:16] they are correct enough for rc1, perf improvements can happen for 2.1.0 final [17:16] as a feature change, I think 2.1 is either all-or-nothing [17:17] Whitley didn't seem to respond to my last message, so I might pick that up myself [17:18] Ooi, is it likely that 2.1.0rc1 will enter ~bzr-beta-ppa? That ppa is looking a bit unmaintained at the moment [17:25] maxb: afaik it is unmaintained [17:25] interesting... merging 3 times with default merge algorithm, --weave and --lca produce 9, 9, and 11 conflicts [17:25] I certainly would like it to... [17:25] is it normal that --lca produce extra conflicts? [17:26] hi jam [17:26] bialix: as always "it depends" but I do know of cases where --lca conflicts and --weave doesn't [17:26] and IME it conflicts more than weave [17:26] rarely I saw --lca produce less conflicts than --weave [17:26] but very rarely [17:26] as you say it depends [17:27] but in most cases weave rules [17:27] but today there is no criss-cross [17:31] jam: Hmm.... if I was interested in helping it becoming maintained, how would I proceed? [17:32] maxb: as in, you personally maintaining it? [17:33] I'm not sure I'd have the time to cover all the plugins on my own, but I'd certainly be interested in doing bzr and bzrtools === beuno-lunch is now known as beuno [17:35] maxb: I believe we have some documentation on how to build, etc bzr for the ppa in 'doc/developers/ppa.txt' [17:35] with possibly some other needed info in 'releasing.txt', etc. [17:35] IIRC, johnf (who maintains ~bzr ppa) actually uses a slightly different methodology [17:36] but hasn't had time to update the documentation, etc. [17:36] Perhaps the best way would be for me to set up a personal ~maxb/bzr ppa, do some packaging, and then find someone with ~bzr-beta-ppa upload permissions to review? [17:36] (using autoppa to handle releasing for many different platforms, etc.) [17:36] maxb: that would work [17:36] it would also let you experiment and get it right before we start having you send it on to others :) [17:36] btw, I have permissions [17:36] as do all core devs, I believe [17:37] hmm, when you branch do you use a command like #> bzr branch bzr+ssh://user@ipaddr/var/www/webxyz/bzrsrc ./localdir [17:37] as i tried that and it was throwing libgz errors [17:38] jam: If the PPA is known currently unmaintained, it would be useful to users if you could edit its description to declare that, for now [17:40] NET||abuse: that looks approximately correct. If you are getting libgz errors that normally indicates disk corruption [17:42] jam, wasn't at all, if i leave out the localdir location it works fine. [17:43] NET||abuse: that would indicate that the corruption is in "localdir" [17:43] localdir didn't exist [17:43] NET||abuse: if "bzr branch $SOURCE" works but "bzr branch $SOURCE ./target" doesn't, then something is pretty odd [17:43] yup,, [17:44] transient network error ? [17:44] if i try ./target when the dir exists, i get the already exists error [17:44] so i know i have to specify a non existant directory [17:45] transient: i'm on heanet, nation education authority network, very reliable,, no way it screwed up 3 times in a row. === Kosjer is now known as KosjerD [17:46] NET||abuse: just as a strawman, try "bzr branch $SOURCE bzrsrc" which should be the default target [17:46] alternatively... what does 'bzr info' in the local dir say? [17:47] jam, well i've already downloaded it so what can i do.. [17:47] trying again [17:49] the localdir says standalone tree( format: 2a) branch root: . Related branches: parent branch: bzr+ssh://user@ipaddr/var/www/webxyz/bzrsrc [17:49] and that's after trying to branch and failing. [17:49] NET||abuse: it is possible that creating the branch succeeded but building the working tree failed [17:50] in the localdir, you could try [17:50] rm -rf .bzr/checkout; bzr co [17:50] http://paste.pocoo.org/show/168068 [17:50] that's the crash log. [17:51] jam, that sounds right. [17:51] jam, did that, immediately again it tries to export the update and gets the error [17:52] NET||abuse: so I don't quite understand why it would not fail if you did not supply a target [17:52] understanding the difference may be the key [17:52] yeh i know, i've no idea why, [17:52] because *that* traceback clearly indicates garbage data [17:52] but every time i specify a locadir rather than letting it default to bzrsrc? [17:53] NET||abuse: is there a 'bzrsrc' already? [17:53] it's really weird behaviour. [17:53] nope [17:53] bzrsrc is only on remote [17:53] (note you can also always do "bzr branch ...; mv bzrsrc localdir" [17:53] yeh, i've done that already. [17:53] i have /home/me/development/projectxyz [17:53] so i've about 20 projectxyz's on the go in there [17:54] for different sites, bits of code work i do, [17:55] and my normal method of working on a site is in the user dir for the site admin, which usually has a www or web dir adjacent, is to create bzrsrc on all hosts i work on, then i can just copy the web dir's out of bzrsrc WT on the server to live serving location. [18:01] anyone already wrote a testcase for bug #113809? [18:01] Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809 [18:01] otherwise I'm going to do that now [18:18] gerard: are you talking about the discussion from here: https://code.edge.launchpad.net/~craighewetson/bzr/update_with_local_commit/+merge/10320 [18:18] AFAIK, nobody has stepped up to complete it === gerard_1 is now known as gerard_ === elmo_ is now known as elmo === gnomefreak76 is now known as gnomefreak === davidstrauss_ is now known as davidstrauss [19:55] davidstrauss: I'm looking at bug #113809 and I've got some questions [19:55] Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809 [19:55] you wrote the original patch right? [19:56] gerard_: yes [19:57] I made some minor changes, and wrote a blackbox test script [19:57] but I'm wondering what bzr is supposed to do for the test_smoke_update_checkout_bound_branch_local_commits test [19:58] because my patched version now give the error that there are both uncommitted changes and local commits, and that seems right [19:59] I'm a little confused about the situation there.... its a lightweight checkout of a branch (and a master) [20:00] and it does 1 commit to the master and 1 to the branch [20:00] then it makes some changes in the lightweight checkout [20:00] after that, it runs bzr update [20:02] I'd expect it to only get the changes from the branch [20:03] but it seems the smoke test (and current implementation) also expects the commit on master to show up [20:04] davidstrauss: any ideas? [20:05] gerard_: My fix does not affect lightweight checkouts [20:05] gerard_: Lightweight checkouts cannot handle local commits [20:05] gerard_: Nor did I write that test :-) [20:07] bzr blame to the rescue ;) [20:07] vila: you there? [20:08] davidstrauss: it seems my adaptation of your fix does affect lightweight checkouts :p [20:08] gerard_: Nor should it. My fix is irrelevant to lightweight checkouts. [20:10] yeah, it should be [20:15] Hrmm. [20:15] can I not rebase in a bound branch? [20:16] bzr: ERROR: Bound branch BzrBranch7('file:///home/codyc/bzr/smartbear/wc/') is out of date with master branch BzrBranch7('file:///home/codyc/bzr/smartbear/dynreport-newcols/'). [20:16] I start with a clean checkout. then try to rebase. [20:17] then I get the above error and get a working-tree with an odd state. [20:17] I'll try it in a standalone branch. [20:21] yeah, seems to be working much better w/o the bound branch. [20:21] maybe it should warn you about that? ;) === salgado is now known as salgado-afk === NfNitLoo` is now known as NfNitLoop [20:35] how can I check I'm in a lightweight checkout? [20:42] gerard_: gerard_ bzr info, I think. [20:42] * NfNitLoop checks. [20:42] yep, the Location: will say "light checkout root: " [20:45] this looks like the check it is using: if (tree is not None and tree.bzrdir.root_transport.base != branch.bzrdir.root_transport.base) [20:45] hmmm === mwhudson_ is now known as mwhudson [20:49] gmbl [20:50] the real problem here seems to be that bzr update will happily do a string of merges, even if there are conflicts along the way [20:50] so if you update, it will merge with the branch you bound to, and then with the branch that branch is bound to etc etc [20:52] just found an easily reproducable bug in bzr-gtk see https://bugzilla.redhat.com/show_bug.cgi?id=557573 [20:52] bugzilla.redhat.com bug 557573 in bzr-gtk "[abrt] crash in bzr-gtk-0.97.0-2.fc12" [Medium,New] === davidstrauss is now known as davidstrauss-afk [21:42] is Robert Collins around? [21:46] gerard_his handle is lifeless [21:46] and he pretty much always lurks :) [21:46] I think he is at LCA this week, so I don't know if will be around to answer right away [21:55] ok [21:55] currently bzr update will keep on merging as long as it encounters a bound branch that is not up to date [21:56] I think it should stop after one merge and notify the user [21:57] because the way it currently is causes a mess with local changes and bound branches [21:58] even when there are no local changes but just conflicts between commits on the chain from master to bound branch to bound branch to bound branch [21:58] I found a comment in the code wondering if it is such a wise Idea to allow binding to an already bound branch [21:59] jfroy: are you around at all? i'm having some problems getting bzr-keychain to do anything [22:02] gerard_: whoah, I never even thought of doing that. [22:02] (binding to a bound branch.) [22:03] does that chain? [22:03] I think so.... [22:04] but you can get conflicts in the conflicts in the conflicts currently [22:04] Glenjamin, gerard_: no, commit will stop if it sees a bound branch of a bound branch [22:04] so you can end up with a file.moved.moved etc [22:04] gerard_: the update you are talking about is different [22:04] jam: commit will, but update wont [22:04] and has to do with local commits + local changes + remote ones [22:05] gerard_: I'm not positive, but i'm pretty sure it only looks at 1 master [22:05] jam: really? [22:05] hmm [22:05] gerard_: yep, but in a heavyweight checkout you have [22:05] 1) the current revision of the working tree [22:05] 2) local modifications to the working tree [22:05] 3) the current revision of the local branch [22:05] 4) the current revision of the master branh [22:05] branch [22:06] and 'update' is currently designed to "smush" that so that [22:06] 1 == 3 == 4 [22:06] and we can only do a 3 way merge [22:06] forcing people to do a local commit first isn't going to work [22:06] hi, I'm in the process of installing the latest Bazaar on OS X 10.6.2, found I had a previous v 1.3 installed apparently. Is there an uninstaller for 1.3 somewhere? Or what do I need to do to get rid of it? [22:07] because there are lightweight commits [22:09] so we should just do one of the merges (3,1,2) [22:09] and then push [22:09] hmm, the fist time a package fails to install... and it's the bzr upgrade in karmic.. [22:10] hmmm [22:10] this is hard [22:10] for a lightweight 1 == 3 right? [22:11] ah, it doesn't have to [22:18] kbrown: I generally just run the installer and it will overwrite the old version. [22:19] kbrown: if you want to be paranoid, you could find the bzrlib directory in your python libraries and delete it. [22:20] the one issue I discovered was bzr was in /usr/bin before and now is in /usr/local/bin, when I did bzr from Terminal it does not pick up the correct one it seems [22:20] kbrown: aah, yep. Delete the old one. [22:20] kbrown: I have also wished for an uninstaller, but I don't think there is on. :/ [22:20] one* [22:21] did that, I suppose the bzrlib is ok then after the new install? [22:23] kbrown: Yep. the bzr executable will complain otherwise. [22:23] (It'll tell you that the exe and library versions differ.) [22:24] bzr log doesn't show revision 0? [22:25] No, rev0 doesn't exactly exist. [22:25] aww [22:25] that's the classic vcs problem [22:25] revision 0 is a theoetical thing [22:25] It got caught in flagrante delicto with rev -1, so we banned it for life. [22:25] so I can have a theoretical thing with a date and a commit message? [22:25] doesn't sound too theoretical to me [22:26] NfNitLoop: thx [22:26] lifeless: anyway, I wanted to ask you something [22:26] about the double merge that bzr update sometimes does [22:27] if the first step has a conflict things get seriously messed up === jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0rc1 and 2.0.4 have gone gold [22:28] I did quite some bzr annotate and it seems you were the one to add that second merge [22:28] yes [22:28] so bzr should just stop there [22:29] that's my current assumption [22:29] but I'm not too sure [22:31] I've checked with abentley who wrote the main merge code and he still thinks stopping there would be good [22:32] does the rest of the code allow a commit after the merge stops at that point? [22:33] something in the situation has to change, otherwise rerunning merge will not have any effect [22:33] ehm, rerunning update* [22:36] fix the conflict, run update again. [22:36] should work f ine in the postulated situation. [22:36] bbiab, fooding [22:36] so only stop when there is a conflict? [22:36] because it seems the policy of bzr to always explicitly commit after a merge [22:41] yes, that should be fine here. [22:41] you won't need to commit after the first merge in this situation. [22:42] because its an update. [22:42] I keep feeling like I've almost found the silver bullet, and then realizing I skipped a step. [22:43] A lot of the stuff I deal with at work is still on raw FTP with no source control, despite a very slow process that has been under way for several months now to try to move everything to svn (and the stuff that is on svn so far is doing it wrong). [22:45] I was trying to figure out a way that I could still use bzr to make my own life easier, but I keep running up against the fact that in order for it to work, either everyone else would have to stop doing direct ftp, or I'd have to be able to install bzr on the server. [22:45] Oh well. [22:47] Kilroo: sounds like a good time to look for a new job? :p [22:47] I was thinking that a silver (or other metal) bullet would be a useful tool to stop the direct FTP 8-} [22:47] Seriously. If you're at a company that's seriously doing development via ftp in 2010... run. [22:48] Yeah, well, if I can get them to stop dumping major database projects on me for a little while, I'm going to try to do something to change that. [22:52] can anyone help me? bzr doesn't want to upload my new branch. Ive done init and add, but it says I don't have permissions when it gets to push... [22:52] Unfortunately my campaign is going to involve going up against a systems administrator who is leery of DVCS (and I think might actually like cvs better than svn) and thinks fusionforge is good stuff, and two levels of supervisors who are going to be very hard to sell on using something like Redmine instead of the VIP Task Manager program we're using now... [23:07] I've been reading through some stuff about the differences between git and bzr lately. It can get pretty interesting. [23:07] lifeless: not performing the second merge loses your uncommitted changes [23:08]