[00:45] <wilco> I see there's bzr-svn which seems to work like git-svn, where I keep my central SVN repo; is there an svn gateway for the hold-outs? Most of my team wants to use something more advanced than svn, but there are a few low-level folks that would need too much re-training
[00:47] <amanica> wilco, I'm not sure what you mean. You can keep everything in a svn repo and then use bzr-svn as a svn client
[00:48] <amanica> I do that a lot, but I prefer to use bzr for central server too
[00:49] <wilco> I'm thinking of something like git-cvsserver, but for bzr & svn... I don't want to hobble my central-server-side capability but I want to not break everyone's docs + training
[00:50] <amanica> wilco, I don't know of a something that works like that. afaik if you want to have pure svn clients, you need a pure svn server
[00:51] <wilco> I see
[00:51] <wilco> Thanks for the info
[00:51] <jelmer> wilco, there is an experimental svn server on top of bzr, but it's not finished yet
[00:51] <jelmer> wilco, 'bzr serve --svn' IIRC
[00:56] <wilco> jelmer: Interesting; thanks.
[00:58] <wilco> any idea of how incomplete it is? I don't see anything in the bzr package docs
[01:00] <jelmer> wilco: it only implements some parts of the svn smart server protocol, e.g. "svn log". It lacks a few important commands, including checkout.
[01:00] <spiv> Good morning.
[01:01] <jelmer> wilco: it's built as a thin layer on top of bzr-svn. I started on it about a year ago but haven't had time to spent on it since.
[01:01] <poolie> hi spivvo
[01:01] <wilco> Oh. I was hoping "incomplete" meant a lack of svn attributes and such.
[01:05] <AfC> jelmer: I know you did a bzr-git release recently. Any chance we can get someone  to put that into the Bazaar PPA?
[01:05] <AfC> bzr-git crashes for me at the moment, unfortunately [I mean, sure, {shrug} but I daresay it's long since fixed]
[01:08] <jelmer> AfC: I'm happy to upload to the PPA just now, but I won't make any promises about keeping it up to date...
[01:08] <jelmer> poolie, spiv: Who is maintaining the PPA these days?
[01:08] <AfC> jelmer: hey sure :)
[01:09] <AfC> Come to think of it, shouldn't bzr 2.2 be in the PPA now, too?
[01:09] <AfC> anyway
[01:09] <AfC> boat to catch
[01:10] <poolie> jelmer, mostly me?
[01:10] <poolie> feel free to upload
[01:10] <jelmer> poolie: ok
[01:11] <jelmer> I've just asked the Debian release team for a freeze exception for bzr 2.2 in squeeze
[01:11] <jelmer> bzr was released just one day after squeeze was frozen, apparently :-/
[01:24] <poolie> oops
[01:24] <poolie> did they have 2.2b4? it's a tolerably small change from that
=== mwhudson_ is now known as mwhudson
[02:08] <AfC> jelmer: sorry to drop out on you
[02:22] <lifeless> AfC: jelmer has halted() :)
[02:22] <AfC> lifeless: just so as someone reboots him in the morning, we're fine.
=== Ursinha-bbl is now known as Ursinha
=== spm changed the topic of #bzr to: Launchpad down/read-only from 0800-0930 UTC for a code update | Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.2-final has gone gold, build those installers
=== Ursinha is now known as Ursinha-zzz
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann
[09:09] <spiv> Launchpad down... sounds like time to finish work for the day :)
[09:31] <poolie> good night spiv
[09:40] <sender> Hi, question: I'm trying to push and get this warning: bzr: ERROR: Working tree "/var/www/" has uncommitted changes (See bzr status). Use --no-strict to force the push.
[09:41] <sender> Running bzr status, gives me no output. Anyone has an idea what's going on?
[09:42] <poolie> sender: that's strange
[09:42] <sender> poolie: thanks... I thought so too. I've tried to sudo both commands. Don't know if that could help, but it didn't. :(
[09:43] <poolie> and does the push succeed if you do use --no-strict
[09:43] <poolie> sudo isn't likely to help except for things like permission problems
[09:43] <sender> poolie: bzr status -S gives me: +   database/db.sql
[09:44] <sender> poolie: I just rm'ed this file... it was never versioned.
[09:44] <sender> poolie: is it normal that something shows up in bzr status -S, and not with bzr status?
[09:45] <poolie> no!
[09:46] <sender> :(
[09:46] <poolie> what does 'bzr --version' say?
[09:47] <sender> Bazaar (bzr) 2.1.1
[09:48] <sender> poolie: can this be a cause: I got permission errors on ~/.bzr_log, I've chown'd that file to my own user
[09:49] <sender> poolie: is there a way to verify my bzr repo?
[09:49] <poolie> 'bzr check'
[09:49] <sender> poolie: running bzr check now
[09:49] <poolie> so bzr status really just says nothing?
[09:52] <sender> that's correct
[09:52] <poolie> sender: that's really weird, i can't imagine a bzr bug that would make things show up in short mode but not otherwise
[09:53] <sender> poolie: bzr check didn't return any errors so it seems
[09:53] <poolie> what does 'bzr st database/db.sql' show you?
[09:53] <poolie> or 'bzr ls' that file
[09:54] <mvo> I get the following error on bzr diff http://paste.ubuntu.com/476834/plain/ (version 2.2.0)
[09:54] <mvo> is there anything I can to do recover?
[09:54] <sender> poolie: bzr: ERROR: [Errno 2] No such file or directory: '/var/www/database/db.sql'
[09:54] <sender> poolie: on bzr ls that file
[09:54] <poolie> sender: and 'bzr info'?
[09:55] <sender> poolie: bzr status that file gives me nothing
[09:55] <sender> poolie: (format: 1.9-rich-root)
[09:55] <poolie> sender: is that file perhaps a symlink ?
[09:55] <sender> poolie: and related branches... normal stuff
[09:55] <sender> nope
[09:55] <poolie> how about plain 'ls -ld /var/www/database/db.sql'
[09:55] <mvo> is that/could that be releated to LP being down?
[09:55] <sender> poolie: no connection with LP
[09:56] <sender> poolie: it's a local project
[09:56] <sender> poolie: ah I remember: I added the file, then rm
[09:56] <sender> 'ed it (sorry for the \n)
[09:57] <sender> poolie: I think I might be able to resolve it by reverting the file...
[09:58] <sender> poolie: but that doesn't change the fact that status and status -S have a different output
[09:58] <sender> poolie: and that I can't push without --no-strict...
[09:59] <poolie> mvo: it's possible, but it's probably not related
[10:00] <poolie> mvo: is this a new local branch?
[10:01] <poolie> mvo, can you please file a bug and ask jam to help when he wakes up?
[10:01] <mvo> poolie: its a checked out branch I was using for some time but recently upgraded to the latest format
[10:01] <mvo> poolie: sure, will do
[10:03] <mvo> thanks!
[10:05] <sender> poolie: should I try to revert the file? Or did I hit a serious BZR bug?
[10:10] <sender> poolie: Ok bzr revert . did resolve the problem
=== spm changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.2-final has gone gold, build those installers
[12:38] <quicksilver> bzr merge from an old repo format into a new one is a bit broken
[12:38] <quicksilver> you probably don't care much but I thought I'd remark on it.
[12:52] <bialix> quicksilver: please, file a bug report
[12:53] <quicksilver> first of all it said "ERROR: Branches have no common ancestor, and no merge base revision was specified"
[12:53] <quicksilver> which was not the case
[12:53] <quicksilver> and then after specifying revision numbers it came up with hundreds, lierally, of conflicts.
[12:53] <quicksilver> upgrading the old repo first fixed it all.
[12:56] <quicksilver> I'm not really in a positon to file a reasonable report, and I don't have time today.
[12:56] <quicksilver> I'll make a note to try to do so next week.
[13:00] <bialix> quicksilver: error about common ancestors seems familiar for me, what is your bzr version?
[13:00] <quicksilver> just checking.
[13:01] <quicksilver> 2.1.0
[13:01] <quicksilver> the "new" format repo was Bazaar Branch Format 7 (needs bzr 1.6)
[13:01] <quicksilver> the "old" one was Bazaar Branch Format 6 (bzr 0.15)
[13:02] <bialix> what is repo format?
[13:02] <quicksilver> I thought that's what that was
[13:02] <quicksilver> how do I find out?
[13:03] <quicksilver> I did cat backup.bzr/branch/format
[13:03] <quicksilver> to get that part above
[13:03] <bialix> bzr info -v
[13:03] <quicksilver> but you need it for backup.bzr I guess?
[13:03] <bialix> it said about both branch and repository
[13:03] <bialix> maybe
[13:03] <quicksilver> ah
[13:03] <quicksilver> cat  backup.bzr/repository/format
[13:03] <bialix> then repository/format
[13:03] <quicksilver> Bazaar pack repository format 1 (needs bzr 0.92)
[13:04] <quicksilver> new is Bazaar repository format 2a (needs bzr 1.16 or later)
[13:08] <bialix> ah, rich-root vs poor-root
[13:08] <bialix> I'd suggest to check with bzr 2.2
[13:18] <quicksilver> bialix: If I copy the old backup.bzr to .bzr then I have the old repo back for reproduction purposes, right?
[13:18] <quicksilver> (there never was a working tree anyway)
[13:18] <bialix> yep
[13:18] <bialix> sorry, bbl
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann
=== Ursinha-zzz is now known as Ursinha
=== deryck is now known as deryck[lunch]
=== Ursinha is now known as Ursinha-lunch
[16:20] <jam> mvo: hey, I missed the start of the conversation, but I'm around if you wanted to chat about something
[16:34] <thrope> is there a way to get a list of controlled files? ie like bzr status but list files that are unmodified
[16:35] <mvo> jam: I had a problem with my bzr branch, I solved it/worked around it now by using the .bzr dir of a fresh checkout. its the first time this ever happend to me, so it might just be local corruption, not sure its woth debugging it
[16:36] <thrope> ah bzr ls -V is what I was looking for
[16:46]  * lamont found 616878 to be most annoying
[16:47] <jelmer> bug 616878 ?
[16:47] <ubot5> Launchpad bug 616878 in bzr (Ubuntu) "bzr commit error because of no identity (affected: 1, heat: 8)" [Undecided,New] https://launchpad.net/bugs/616878
[16:47] <lamont> perfectly good repo, commit requires 2 commands instead of 1
[16:47] <lamont> in about 400 repos
[16:47] <lamont> with something like 10 users
[16:48] <mgz> if you're really doing it that many times, you can write yourself a two line shell script
[16:49] <jelmer> lamont: previously bzr would use "$USERNAME@$HOSTNAME" and that caused some people to do a lot of commits without a valid email address. IIRC that was the reason this check was put in place.
[16:50] <jelmer> allowing anonymous commits is reasonable, perhaps we should have "bzr whoami --anonymous" ?
[16:50] <jelmer> or maybe just "bzr commit --anonymous" ?
[16:50] <mgz> that bug should probably be converted into a question or something
[16:51] <mgz> I agree the --anon commit idea is good though, provided it doesn't just get misused
[16:51] <lamont> mgz: yes, we could, and we will.  just not very happy about it.
[16:51] <mgz> well, surely it's better than leaking your username and hostname into the repo?
[16:51] <lamont> these repos never do anything that has anything to do with emailing anything.
[16:52] <lamont> nor does the repo ever leave the machine in question, other than in backups
[16:52] <jelmer> lamont: Is it really anonymousness you're after or just wanting to avoid extra configuration ?
[16:52] <jelmer> it sounds like it's more about configuration than anonymousness
[16:52] <lamont> it's really just having bzr commit keep working across the upgrade that I'm after... really don't care what the user/email addr are in the commit
[16:53] <mgz> okay, so we've caused you some pain.
[16:53] <jelmer> lamont: So it's the extra configuration that was previously not necessary.
[16:53] <mgz> in your case for no gain, but bar reverting the change (which I think is a bad idea), what can we actually do to help you?
[16:54] <jelmer> lamont: it will use the EMAIL or BZR_EMAIL environment variables if set, if that helps.
[16:54] <lamont> jelmer: does it only care about email?
[16:54] <jelmer> lamont: it doesn't really care about the value, just that there is something set explicitly.
[16:54] <lamont> cool
[16:55] <lamont> jelmer: you wanna throw that into the bug as a comment/workaround suggestion?
[16:55] <lamont> otherwise, I will
[16:55] <jelmer> Yeah, sure
[16:56] <lamont> ta
[16:58] <jelmer> mgz: what do you think about warning rather than errorring out completely ?
=== deryck[lunch] is now known as deryck
[17:00] <Ng> what about etckeeper? it is a robot doing commits to bzr. a robot with no email address
[17:00] <Ng> just as a random thing in the ubuntu archive which does non-humanic commits ;)
[17:01] <jelmer> Hi Chris
[17:01] <jelmer> Ng: it sets EMAIL explicitly IIRC
[17:02] <Ng> if it is, it's using $USERNAME@$HOSTNAME? ;)
[17:03] <jelmer> yep
[17:03] <mgz> jelmer: but what would bzr do after issuing the warning?
[17:03] <jelmer> ./commit.d/50vcs-commit:		export EMAIL="$USER <$USER@$hostname>"
[17:03] <jelmer> mgz: continue on doing the commit
[17:03] <mgz> using what as the email?
[17:04] <jelmer> mgz: the guessed email address (as we did prior to 2.2). The user can always uncommit and recommit with an email address set.
[17:04] <mgz> part of the reason I'm glad so see the old code go is that trying to interpret `username + "@" + hostname` as an email adress lead to a lot of bugs
[17:04] <mgz> both are unicode on windows, and can contain spaces
[17:05] <mgz> this means unicodeerrors, and code trying to split things getting confused by extra spaces, and so on.
[17:05] <jelmer> hmm
[17:05] <Ng> jelmer: well then that's not a great example ;)
[17:05] <mgz> also, having my local username and hostname end up in some public repo is a bad thing.
[17:06] <Ng> mgz: because of your specific circumstances, or general position?
[17:06] <mgz> I prefer getting yelled at.
[17:07] <jelmer> I like being told, but not being blocked.
[17:07] <mgz> ng: well, a general position, it's a Bad Thing.
[17:07] <jelmer> Perhaps we could just use $USERNAME
[17:08] <mgz> one repo I poked on launchpad had four different contributors depending on which box the guy who owned it was hacking from.
[17:08] <lamont> other VCS implementations going back a decade or so use $USERNAME@$FQDN
[17:08] <lamont> rather than the short hostname
[17:08] <mgz> might work on a university box,
[17:09] <mgz> but who has a sensible domain set up from their home machine?
[17:09] <Ng> mgz: why does that matter?
[17:09] <lamont> mgz: many of us do
[17:09] <mgz> I like clean repos with readable blame and stats.
[17:10] <Ng> then make whoami procedure for your employees :)
[17:10] <mgz> I'm a lone hacker, and it's other people's repos I worry about.
[17:10] <jelmer> mgz: I don't think that's a reason to force everybody to have a sane committer email address...
[17:10] <mgz> I think telling them is better than using an insane address.
[17:11] <elmo> mgz: you're assuming the email address matters
[17:11] <mgz> if they want to use something odd, they can set whoami to (nearly) whatever they like
[17:11] <jelmer> mgz: Telling them is different from forcing them to use a sane address.
[17:11] <elmo> mgz: that's not a reasonable assumption
[17:11] <mgz> I think the user *id* matters
[17:11] <mgz> which unfortunately means Name <Email>
[17:12] <mgz> the user id is baked into every commit made.
[17:12] <Ng> what this discussion clearly shows to me is that this is a local policy issue
[17:13] <mgz> what this discussion shows is that four people are awake currently.
[17:13] <jelmer> mgz: I count 5 >-)
[17:13] <mgz> I don't think you can draw big conclusions, but bugging people is always unpopular, sure.
[17:14] <mgz> whatever happens that isn't a return to buggy code that doesn't even make much sense on nix, I'll live with
[17:15] <lvh> hey
[17:15] <jelmer> hi lvh
[17:15] <lvh> any eclipse+bzr users here? I'm somewhat confused as to how you use the plguin effectively
[17:15] <lvh> the only way I can figure out is if you use lightweight checkout and switch all the time
[17:16] <mgz> switching is fine.
[17:16] <lvh> the other way is if each branch is its own project
[17:16] <lvh> mgz: I've never done it. What docs should I read? bzr switch manpage?
[17:16] <mgz> you can have a shared repo with no trees, and one tree under it for eclipse
[17:16] <mgz> then switch that tree between the other branches on the repo as you work on them
[17:17] <mgz> I think there was something on the list quite recently with directions you could read...
[17:17] <maxb> That's basically the only way I can see making sense - it's a shame Eclipse makes it so hard to add/remove projects.
[17:18] <lvh> yeah
[17:18] <lvh> it's definitely eclipse's fault but you know it's a sad day when hg integration makes me happier than bzr integration
[17:18] <maxb> Well... MercurialEclipse is vastly more advanced than bzr-eclipse
[17:19] <maxb> And qbzr-eclipse, whilst useful, isn't exactly an Eclipse integration
[17:19] <maxb> I would love to push bzr at work, but this is my primary inhibitor
[17:19] <jelmer> mgz: fwiw I don't think we should pretend we can guess the email address by using $USERNAME@$HOSTNAME. I'd rather just use the $USERNAME as the full committer text and be done with it; we already have to deal with that situation in other cases anyway when we import committers from svn or cvs.
[17:20] <mgz> jelmer: encoded as utf-8?
[17:21] <jelmer> mgz: Yeah (we already mandate that the committer field is encoded as utf8)
[17:23] <mgz> lvh: this is actually about large repos, but the workflow is the one you want: https://lists.ubuntu.com/archives/bazaar/2010q3/069499.html
[17:24] <mgz> (maxb can correct me if there's anything wrong)
[17:25] <maxb> I don't think so
=== Ursinha-lunch is now known as Ursinha
=== beuno is now known as beuno-lunch
[18:20] <basic`> Hi everyone, is it possible to force filesystem permissions in bzr?  We're using it for drupal.org webroots and for whatever reason new files are being added with rw------- / 600 permissions that can't be read by the webserver
[18:21] <basic`> has anyone hit an issue similar to this?  the files in the repository checkout that the commits are coming in from have 664 permissions
[18:21] <basic`> i read over https://bugs.launchpad.net/bzr/+bug/67589 but it didn't seem to be the right issue
[18:21] <ubot5> Launchpad bug 67589 in Bazaar "bzr does not store permissions (affected: 0, heat: 1)" [Wishlist,Confirmed]
[18:34] <maxb> basic`: I would check the umask of the user executing bzr on the webserver
[18:34] <basic`> maxb: it's 022 like the other users
[18:34] <maxb> that is surprising
[18:35] <basic`> it should be creating directories with 755 and files with 644
[18:36] <basic`> and it seems to be working for the other sites under bzr.. let me test
[18:38] <basic`> maxb: actually... i take that back it looks like the umask is different on the box that has the nfs mount and these updates are being run... that explains it
[18:39] <basic`> wait, it's even more permissive on that box (0002)
[18:39] <maxb> odd.
[18:39]  * maxb afk now
[18:39] <basic`> maxb: thanks :)
=== beuno-lunch is now known as beuno
[20:22] <dlee> Trying to find revisions lost on revert.  Sequence done: unbind, local commits, bind, update... got a bunch of unexpected conflicts apparently caused by case differences in folder names... mistake?: did a revert, but now I can't find any of my local revisions.  Can I get them w/o knowing revids??
[20:23] <james_w> dlee: "bzr heads --dead"
[20:23] <james_w> from bzrtools
[20:24] <james_w> that should show you the tip revision you had before the upload
[20:24] <james_w> update I mean
[20:25] <dlee> I thought bzrtools was integrated now... uknown command "heads" bzr 2.0.0 here.
[20:26] <dlee> I can probably get that part to work... but on finding it, can I still reintegrate those local commits?  I had planned to do update/rebase/commit to update the upstream repo.
[20:30] <dlee> Found the revids using a 2.2.0 where "heads" works... so down to that above question. :)
[20:35] <james_w> dlee: you can either "bzr pull --overwrite -r revid" to get back to where you were before you started
[20:35] <james_w> or "bzr merge . -r revid" to get back to where you were before the revert
[20:36] <dlee> Hmm... pull, when the found revid is only local?
[20:37] <james_w> err, yeah, with a dot as well, sorry
[20:37] <james_w> "bzr pull . --overwrite -r revid"
[20:38] <dlee> Trying to decide which makes more sense for the ultimate goal, which is to upload my local commits onto the upstream branch, presumably after a rebase.
[20:39] <dlee> Ah ... the "pull" should literally rewrite everything to where it was, then I can try the original merge again... wonder if --reprocess will help deal with the mess of foldername conflicts...
[20:43] <dlee> Getting "no such revision" on "bzr log -rrevid:<foundID>" and a traceback, in 2.0.0 and 2.2.0.
[20:46] <basic`> maxb: so i'm as stumped as you are with the permissions thing... doing another bzr checkout of the tree has the correct permissions
[21:01] <dlee> JamesW:  Ouch... your "pull --overwrite" suggestion worked, but I forgot to unbind first!  Result: I overwrote the upstream branch with my local one.  Odd though, the upstream branch is supposed to forbid history alterations.
[21:02] <dlee> The error I mentioned earlier is a bug in "log": It crashes trying to convert a revid to a dotted revno.  I'll file that one when I can.
[21:04] <orospakr> Hi!  I'm looking through the docs, but I can't find a mode I thought exists for having a smart-server's repo containing multiple-branches in place.  at least, I don't want to have to make a copy of my entire repo on my server for every new branch I want to have.
[21:05] <orospakr> (my workflow is creating a new branch for each new ticket of work, so super-cheap branches are a must)
[21:06] <orospakr> ah, http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/shared_repository_layouts.html#nested-style-project-branch-sub-branch
[21:06] <orospakr> I think.
[21:10] <dlee> orospakr: yes, sounds like a perfect time for a shared repo structure.
[21:12] <orospakr> hm. with that approach (init-repo), do I have to create all new branches on the server by sshing to it and typing a `bzr branch` command in locally?
[21:25] <dlee> orospakr: You can do that, but you can also push a branch from elsewhere if you have one to push.  Do all branches start from one common branch?
[21:26] <orospakr> yeah, everything ultimately has a common ancestor. You're saying that if I happen to fork a new branch on my dev machine, I can push that into the server's shared repository without interacting directly with a shell on the server?
[21:26] <dlee> I doubt "bzr push bzr+ssh://my.domain.com/var/bzr/proj/branch5" from a local copy of the main branch would cost that much... Others can correct me of course, but I doubt that sends all the texts from local to server when the server has a shared repo for the branches.
[21:27] <orospakr> ah, so if I just give it the path with $existing_repo/my_new_branch, it should Just Work?
[21:27] <dlee> orospakr: Yes:  If you have, say, done "bzr co bzr+ssh://my.domain.com/var/bzr/proj/trunk," you can do what I showed above to make branch5.
[21:27] <orospakr> ie., bzr push  bzr+ssh://myserver/$existing_repo/my_new_branch
[21:28] <orospakr> sweet. it worked!
[21:28] <orospakr> thanks.
[21:28] <dlee> orospakr :)
[21:29] <orospakr> it'd be a bonus if I could avoid typing the "bzr+ssh://myserver/$existing_repo" part every time I want to make a new branch there.
[21:29] <orospakr> or rather, *push to* a new branch there.
[21:30] <dlee> orospakr: (1) shell variables.  (2) "bzr bookmarks" etc., if you have bzrtools (I believe that's part of bzrtools at least)
[21:31] <fullermd> Separate plugin.
[21:32] <dlee> oops thanks
[21:33] <orospakr> hm. I wonder, I want to figure out how my colleague can pull that branch onto her machine, without having to make an entire new local branch, with redundant storage of all the history that is already in her local repo of the main branch of our project.
[21:34] <orospakr> I guess she could branch her local one, and then pulled the new branch from the server into that new local branch.  Requires more steps that I think would be elegant, though.
[21:37] <rocky--> jelmer, hey... when i merge from a remote svn branch, commit changes in my local branch, and then push back... i get an error saying operation denied because it would change mainline history... did i do something wrong
[21:37] <rocky--> ?
[21:38] <jelmer> rock--: No, but you have to realize your change would remove the current tip from the remote branch and replace it with your merge revision.
[21:38] <rocky--> hm that sounds more intrusive then i'd like
[21:39] <jelmer> rocky--: That's why it's requiring you to set a configuration option before allowing that.
[21:40] <rocky--> is there a less intrusive thing i could have done to achieve a similar result?
[21:50] <jelmer> rocky--: rebase
[21:51] <jelmer> or you could've merged your branch into an up to date copy of the remote branch and pushed that.
[21:59] <dlee> JamesW:  If you're still here, thanks much... got all cleaned up and rebased and in sync.
[22:16] <quotemstr> Say I have a branch in ~/foo/bar/trunk; I'd like to convert ~/foo/bar to a shared repositroy.
[22:16] <quotemstr> Can I do that by just running (with CWD being ~/foo/bar) bzr init-repo . and bzr branch trunk trunk2 ?
[22:20] <jelmer> quotemstr: yes, although you can also do:
[22:20] <jelmer> bzr init-repo . && cd trunk && bzr reconfigure --use-shared
[22:20] <quotemstr> Thanks.
=== Ng_ is now known as Ng
=== cody-somerville_ is now known as cody-somerville
=== jpds_ is now known as jpds