[06:56] <vivekimsit> Hi, I just want some immidiate help :(
[06:56] <vivekimsit> I have checkout one branch from launchpad
[06:57] <vivekimsit> now I am on rev12 and my collegue is on rev19
[06:57] <vivekimsit> how can I get my code updated?
[06:57] <spiv> vivekimsit: 'bzr pull'
[06:58] <vivekimsit> ok! I was really confused b/w pull and up, pls can u tell me something about up also and thanks
[06:58] <spiv> (Or perhaps 'bzr update' if you used 'bzr checkout' rather than 'bzr branch' to get the branch; refer to the docs for the details if you want)
[06:59] <spiv> In short: update updates a checkout to be current with the branch it is a check of.
[06:59] <spiv> 'pull' updates a branch to be current with another branch (by default the branch it was branched from).
[07:00] <vivekimsit> I used bzr co!
[07:01] <vivekimsit> so I should use up?
[07:04] <vivekimsit> I am getting an error while doing 'up'
[07:06] <vivekimsit> bzr+ssh://bazaar.launchpad.net/~synerpgy/synerpgy-projects/destock_dev/
[07:06] <vivekimsit> bzr: ERROR: No WorkingTree exists for "bzr+ssh://bazaar.launchpad.net/~synerpgy/synerpgy-projects/destock_dev/".
[07:11] <fullermd> You sure you're just doing "bzr up", not putting stuff after it?
[07:13] <vivekimsit> shit! I did this : bzr up lp:~synerpgy/synerpgy-projects/destock_dev
[07:14] <vivekimsit> ok! how to undo my last commit ?
[07:18] <LarstiQ> vivekimsit: so for the update do `bzr up` instead of `bzr  up lp:~synerpgy/synerpgy-projects/destock_dev`
[07:18] <vivekimsit> ok
[07:18] <LarstiQ> vivekimsit: then, if your question about commit is unrelated to that, use `bzr uncommit`
[07:18] <LarstiQ> if it is related, maybe I should first figure out what exactly is going on
[07:29] <vivekimsit> Ok! now some more small problem
[07:30] <vivekimsit> I have done bzr up and now I am getting some weird things in my source !
[07:30] <bob2> do you mean conflict markers?
[07:31] <vivekimsit> <<<<<<< TREE, >>>>>>> MERGE-SOURCE
[07:31] <bob2> == conflict markers
[07:31] <vivekimsit> ya
[07:31] <vivekimsit> So do I need to remove them manually?
[07:31] <bob2> alas bound checkouts make this painful
[07:32] <bob2> iirc
[07:32] <vivekimsit> is there not any command line option to do it automatically
[07:32] <bob2> ?
[07:32] <bob2> the point is that bzr tried to merge automatically and failed, because both sides had touched the same lines of the file
[07:32] <vivekimsit> its means no!
[07:33] <bob2> same thing in every version control system
[07:33] <vivekimsit> ok! can I undo my last update?
[07:33] <bob2> it sounds a lot like you had uncommited changes?
[07:35] <vivekimsit> No, its like I did bzr up, now I want to undo it
[07:35] <bob2> but you did bzr up with uncommited changes?
[07:36] <vivekimsit> yes!
[07:37] <bob2> as far as I know, there's no easy way to get it back
[07:39] <bob2> someone else may know an answer though
[07:39] <bob2> (always commit before doing a thing!)
[07:41] <vivekimsit> ok! the current scenario is I did 'up' and as you know there were some conflicts, and I now there is one more rev in remote branch so I need to do 'up' again. So, I am just afraid that do I need to fix my conflicts first or just do 'up' again and fix conflicts later!
[07:41] <bob2> no, don't up again
[07:41] <vivekimsit> so, what to do I have to make my code upto date!
[07:42] <bob2> what you should have done is commited and done a bzr pull
[07:43] <vivekimsit> actually I did was a co, there I had thought of options either revert it and do up again!
[07:43] <vivekimsit> someone told me here that for co we do upo
[07:43] <vivekimsit> up
[07:43] <bob2> well yeah, but that does this, which is not very useful
[07:49] <vivekimsit> ok! how to manually remove all conflicts?
[07:50] <bob2> by editing the files with a text editor
[07:56] <vivekimsit> so which lines should I remove ?b/w tree and [08:14] <Merwin_> hi
[08:30] <vivekimsit> What is text conflicts?
[08:59] <jave> hello
[08:59] <bob2> == conflicts within the file
[09:00] <jave> I get a weird "killed" message in the middle of merging from a remote repository. locks are left dangling
[09:17] <jam> jave: is it taking a while? It sounds like something is killing your connection. So one option might be to branch locally and then do the merge.
[09:25] <jave> jam: yes it takes quite a while
[09:26] <jave> jam: but I'm not really sure what you mean with a local branch? I already have a branch that I would like to merge from uptstream
[10:29] <jave> this is the Emacs repository btw. I'm using the Fedora 17 beta so maybe there is some issue with the bzr version they provide
[10:30] <jave> Bazaar (bzr) 2.5.0
[12:44] <LarstiQ> jave: jam's suggestion was to `bzr merge path/to/local/copy`, instead of `bzr merge remote/branch`
[13:10] <jave> LarstiQ: okay
[15:23] <nDuff> Hmm. During a "bzr commit" (to a lightweight svn checkout): SubversionException: ("'http://subversion.tigris.org/xmlns/dav/md5-checksum' was not present on the resource", 160013)
[22:09] <wodemaye> Hi, I'm pretty new and trying to learn BZR, but before I invest too much effort into learning it, I want to know if I can essentially use it as a git client.  IE, I want to participate in a project on github.  What I've read tells me that I won't be able to "push" but I can't really figure out what this means.
[22:19] <nDuff> wodemaye: "pushing", in this context, is sending changes you made back into the remote git repository.
[22:20] <nDuff> wodemaye: ...that said, you _can_ use bzr dpush to put your changes from bzr into git, but it's not completely lossless in terms of metadata.
[22:21] <nDuff> the metadata that's lost using dpush probably isn't critical -- things like rename info (which git just doesn't have as a concept)
[22:22] <wodemaye> nDuff, so... I wouldn't lose any metadata on my local metadatabase, right?
[22:23] <wodemaye> and the commit descriptions would go through.  and the updated state of the entire dir under bzr version control will be pushed up to github?
[22:23] <wodemaye> as in all of my actual changes to the codebase would stay intact?
[22:25] <nDuff> the changes themselves would stay intact, yes; the metadata... well, it wouldn't be _destroyed_ as such, but if you're working from the remote branch (which you'd want to do), you wouldn't still be working on the places it's attached to, so its continuing local existence is mostly just academic.
[22:26] <nDuff> the other thing is that I haven't personally used the git foreign branch support, so I can't make promises about its stability
[22:31] <wodemaye> nDuff, no worries. can you please elaborate on working on the remote branch? what does that mean? also, what sorts of metadata is it that gets lost?
[22:35] <nDuff> wodemaye: as mentioned before -- renames, mostly; git refuses by design to think about directories as first-class objects, so it doesn't have any way to record operations on them.
[22:36] <nDuff> wodemaye: ...re: "working on the remote branch" in that context -- presumably after you've pushed your changes, other folks will make other changes on top of them, and you'll want to check out and work from that version, rather than working from your local branch in bzr that still has full metadata attached.
[22:39] <wodemaye> but they would still be reflected in the github version, right? if i branch a github repo, then rename oldname.txt to newname.txt, then dpush the repo back up, then someone else clones the repo with a real git client, they won't see oldname.txt anymore will they?  would it just appear as though i'd deleted oldname.txt and added a new file called newname.txt with coincidentally identical contents?
[22:41] <wodemaye> nDuff, also, you say "things like" ... rename info.  what other things "like" it are lost?
[22:42] <wodemaye> and thanks for answering my qs btw.
[22:47] <jelmer> wodemaye: revision properties, like bug info
[22:47] <jelmer> multiple authors, references to ghost revisions (which are unlikely to occur unless your project was ever imported from svn or baz)
[22:48] <wodemaye> jelmer, k, thx.