=== bob2 is now known as Guest19481
luke-jrbzr diff ../server/e/HEAD/ -c 64 | patch -p000:47
luke-jrwhy does that work, yet bzr merge is too stupid to handle it? :/00:47
luke-jrfuzz 2?00:49
RAOFluke-jr: Answering that would requrire the message bzr gives as the reason it can't merge.00:50
luke-jrit just does conflicts galore00:50
luke-jrI'm merging lp:moo/lambdamoo-1.8 updates into lp:~luke-jr/moo/db_options00:51
RAOFHm.  Not really sure.00:56
lifelessluke-jr: does it detect a criss-cross merge?01:06
luke-jrlifeless: there is no criss-cross, no01:06
luke-jrdb_options has and never will be merged into lambdamoo01:07
lifelessluke-jr: its odd that it is conflicting01:09
lifelesswhat type of conflicts is it giving?01:10
luke-jrthe MERGE-SOURCE side is trying to add about 500 lines of code that was removed in the branch01:10
lifelessyou could try --weave01:12
luke-jrhaha. no.01:12
luke-jrweave is evil01:13
lifelessso you're merging trunk into a branch that hasn't been merged into trunk ever, and its reinstating code that was deleted in the branch ?01:15
luke-jrtrunk is a CVS import, if that is at all relevant01:16
luke-jrbranch was created from a tag in the bzr import01:16
luke-jrI need to manipulate file-ids. Any advice?01:22
lifelesswhy do you need to do that?01:28
luke-jrtelling Bazaar about a rename01:29
lifelessI think you're getting the conflict because the code that was deleted in the branch was altered in the trunk. Is that potentially accurate?01:29
luke-jrlong after the fact01:29
lifelessbzr mv --after01:29
luke-jrit wasn't01:29
luke-jrlifeless: long after, meaning the commit is 50 revisions ago01:29
lifelessre the conflicts - in which case please file a bug01:29
lifelessluke-jr: bzr rm foo --keep; bzr add --file-ids-from [place that has the file] foo01:29
lifelessluke-jr: also --weave isn't evil, its good - mysql use it all the time to get massively less conflicts01:30
luke-jr--weave reduces conflicts, sure, but often it duplicates code01:30
lifelessdoes it? I haven't seen that. That would be a bug IMO01:31
lifelessbasically, feel free to file bugs on merge logic01:31
lifelesssome will be things we can't easily fix without throwing other things out01:31
lifelessbut there is lots of room to improve01:31
luke-jrthe problem-causing merges seem to trigger patch to say "with fuzz 2"01:32
luke-jrI can only presume that's related01:32
BasicOSXgetting only 8kB from LP everything else fast01:35
luke-jrlifeless: any way I can ensure I'm not about to totally screw up my branch? XD01:37
luke-jrbzr status is giving me some funky output ;/01:37
luke-jradded: db_objects.c01:37
luke-jrrenamed: db_objects.c => db_save_objects.c01:38
luke-jrmodified: db_save_objects.c01:38
luke-jrdoes that make sense? :/01:38
lifelessit says that db_objects was modified and renamed01:39
lifelessand that you have added a new fiel db_objects.c01:39
luke-jrtrying to tie these merge trees together is a pain01:40
=== Guest19481 is now known as bob2
chxhow do i get my working tree into where it was before 9841 was committed?04:43
LeoNerdbzr revert -r984004:43
LeoNerdOr.. more accurately, something like   bzr revert -rparent:9841   but that probably comes down to 9840 anyway04:43
chxi thought revert was only for reverting changes since last commit.04:43
chxmy bad.04:43
LeoNerdrevert puts it back to the state at some commit.. by default the most recent... but -r can pick a different one04:44
luke-jrwhat does -rparent do for merges? :p04:55
Peng_Hmm, it's "before:", and the help doesn't say.04:57
vinc456can i reload my bzr.conf file?04:59
vinc456i've made an edit but the changes don't seem to take effect05:00
vinc456sorry branch.conf05:03
Peng_The changes don't take effect...where? There's nothing to reload05:08
vinc456well i defined the alias from the tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html05:09
vinc456but if i try something like 'bzr ll' i get an unknown command error05:10
vinc456i thought i might have to run some sort of source command, the way i do when i edit .bashrc or something05:10
Peng_vinc456: Maybe you have to set that in ~/.bazaar/bazaar.conf.05:12
vinc456Peng_: i set ~/.bzr/branch/branch.conf05:15
vinc456anyways it's not a big deal05:16
vinc456it'll probably work fine once the next time i reboot05:16
Peng_vinc456: Um, no it won't.05:16
Peng_vinc456: ~/.bazaar/bazaar.conf.05:16
vinc456Peng_: ah ok, i was confused05:19
seb_kuzminskydoes cherrypicking lose merge tracking?05:45
seb_kuzminskyi do "bzr merge -c $MY_FAVE_REVNO && bzr merge -c $OTHER_REVNO && bzr commit", and then "bzr log" shows just the final commit, not three new commits (a merge of two previous commits)05:46
seb_kuzminskythat's on bzr 1.1105:46
Peng_seb_kuzminsky: That's correct. Which is why we try to avoid cherrypicking. :D05:48
seb_kuzminskyok thanks Peng05:55
Peng_Sorry. :\05:56
BasicOSXmake check-dist-tarball failing on 1.14rc1 release. Anyone able to look at bug 355454 ?06:00
ubottuLaunchpad bug 355454 in bzr "$ make check-dist-tarball failure" [Undecided,New] https://launchpad.net/bugs/35545406:00
Peng_I don't think Unicode issues like that are new.06:01
BasicOSXwasn't an issue 1.1306:02
Peng_Oh. Never mind then. :D06:03
BasicOSXinteresting bzr selftest passes06:10
Peng_make check tests with multiple LANG values.06:13
Peng_So it's more likely to expose Unicode bugs than just selftest.06:13
BasicOSXAhh, how it make through PQM? I thought the multiple LANG stuff got put into PQM?06:17
* Peng_ shrugs06:18
BasicOSXless shrugs, more answer! :-P06:19
Peng_make check runs with your normal locale and the standard C locale. I'm not sure what PQM does.06:21
Peng_Maybe your specific locale exposes some bug that PQM's setup doesn't.06:22
Peng_That's about all the answer I have.06:22
=== chx is now known as chx_sleeping
glyphI've got a branch that I want to push to a public location.  Unfortunately most of the commits were made before I understand how 'bzr whoami' worked, so they are from "Glyph Lefkowitz <glyph@some-random-host-I-use>" rather than "Glyph Lefkowitz <glyph@twistedmatrix.com>"06:57
glyphIs there a way I can fix up that history?06:57
Peng_Pretty much no.06:59
glyphPeng_: Hmm... I guess I should rebase from zero then?07:00
luke-jrI used cvsps-import to do the initial migration of a CVS upstream to Bzr; how do I get syncs from CVS in?07:00
spivglyph: editing a fast-import dump might be relatively painless, if you really care.  (does it really matter?)07:02
glyphspiv: I don't know.  Does it?  I was under the impression that email address was sort of the primary key for identifying committers.07:03
jkakarglyph: I trust GPG signed commits as a verification method much more than an email address.07:39
glyphjkakar: These commits weren't signed either :)07:47
glyphjkakar: Can I go back and sign them?07:47
bob2bzr sign-my-commits07:48
glyphbob2: Huh07:56
glyphand then if I push somewhere, signatures for old revisions will be published?07:56
bob2also not sure what it'll do wrt your whoami having changed - you might need to temporarily change that back07:56
glyphbob2: It looks like I can pass a committer on the commandline07:57
lifelessglyph: no, old revision signatures are not automatically propogated, because thos revisions are not being examined. The library can do it; I guess we should add a flag to push/pull ; I think there is a bug already open08:09
lifelessglyph: and possibly a hidden command08:09
glyphI guess for now I will not worry about this08:10
jkakarglyph: I have this in my ~/.bazaar/locations.conf, which causes all my commits to be GPG signed: http://paste.ubuntu.com/144726/09:01
glyphjkakar: I'll be adding something like that soon, as soon as I figure out how seahorse-agent works09:02
glyph(I don't like having gpg private keys on my hard drive)09:02
jkakarYeah, that's probably a good call.09:02
jkakarI was doing the SSH+GPG key on a USB stick thing for a while...09:02
glyphjkakar: You stopped?09:03
pygiok, folks, got a tiny problem with push09:03
jkakarbut then I noticed how much easier it was to steal radix's keys (with USB key attached) at sprints, compared to his whole computer, and decided it might not be so bulletproof.09:03
jkakarThough, I guess most of the time my hard drive is potentially more accessible to evil hackers than a USB key in my house, where I spend most of my computing time.09:04
jkakarglyph: So yeah, I stopped.09:04
jkakarI'm probably not paranoid enough, oh well.  Ignorance really is bliss. ;)09:04
kizzoHow would I go about undoing a "bzr add"?09:05
kizzo: )09:05
kizzo[ removing all of the files that were added b/c of that command.. ]09:05
jkakarkizzo: rm `bzr added`09:06
lifelesskizzo: or 'bzr revert' the added files09:06
kizzojkakar: That looks like it would actually delete the files from my disk, huh?09:06
kizzoThe first one.09:07
jkakarkizzo: It will, yes.09:07
kizzoOh ok, so revert is probably what I would like to happen then.09:07
lifelesspywhats wrong?09:10
lifelesspygi: ^09:10
pygilifeless, If I knew that'd be good :p09:11
pygiprobably something with the server :P09:11
pygilifeless, http://slexy.org/view/s21qWJI3Rj09:11
lifelessoh, I can't browse right now09:11
pygibasically, I can't push :D09:13
lifelessdo you get an error?09:13
pygibzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'Operation not supported: open_write_stream')09:13
lifelessthat sounds like you have an _extremely_ old server09:13
lifelessor hmm09:13
lifelessperhaps its backed onto a readonly transport09:13
lifelessthe latter is more likely I think09:14
* pygi is pretty sure he configured rw privs09:14
pygiit might be that security subsystem of this server is a bit wonky09:15
pygiits still pretty fresh09:15
lifelessare you pushing to bzr+ssh/bzr/bzr+http?09:15
lifelesswhat backing transport did you give it in your glue code?09:15
pygihow do you mean?09:16
lifelesswell to setup a bzr+http server you need some wsgi glue09:17
lifelessand in that you tell it where the server backend is09:18
lifelesswhat url did you use in there09:18
pygiyup, moment :p09:18
pygi    local_url = wsgi.local_path_to_url(root)  ?09:19
pygiI mean, I can branch pretty fine, its probably something in the security code or something :-/09:20
pygi(not of bzr security code, but of that wsgi glue/security glue code that you say :)09:21
lifelessdid you follow the howto ?09:22
pygiactually, no, purely because I use a custom-written server (clue-bzrsever)09:23
lifelesscross reference the howto09:23
lifelessif when you start the backend server you are passing in an http transport its fundamentally wrong09:23
lifeless    from bzrlib.transport.http import wsgi09:24
lifeless    smart_server_app = wsgi.make_app(09:24
lifeless        root='/srv/example.com/www/code',09:24
lifeless        prefix='/code/',09:24
lifeless        path_var='REQUEST_URI',09:24
lifeless        readonly=True,09:24
lifeless        load_plugins=True,09:24
lifeless        enable_logging=True)09:24
lifelessis the key bit09:24
lifelessroot needs to be your on disk path to the root you want to serve out09:24
lifelessand you'll want readonly=False :)09:24
pygithanks, I'll see what I can do09:26
pygihm, ok, readonly IS false09:29
pygiis this correct:    write = ['mkdir', 'put_file', 'delete', 'rename', 'rmdir', 'append_file', ]  ?09:30
lifelessthat looks like something to do with your custom server09:30
lifelessits certainly not an accurate list of what bzr uses to push, if thats what you're asking09:30
pygican that be the problem?09:30
lifelessI don't know, I'm guessing at things here09:32
lifelesswhat does this custom server do?09:32
lifelesshow does it hook into bzr?09:32
pygiusing bzrlib09:32
lifelessI mean, it could implement the protocol, or it might subclass the request dispatcher, or handler lookup, or decorate the backing transport, or something else again09:33
lifelessI have no idea about it, today is the first time I heard of it09:33
lifelessand without knowing a fair bit more I can't offer good advice :(09:34
pygilet me check09:34
lifelessI will note that the open_write_stream method is one on transport that isn't exposed in the smart server API, so its possibly decorating the backing transport09:35
lifelessin which case giving it a more complete list would be a good idea:)09:35
pygicould you point me to location where I can find more complete list? :)09:36
lifelesspydoc bzrlib.transport.Transport is the base class for all transports09:36
lifelessit defines the public api09:36
lifelesspygi: what does the custom server do for you?09:38
pygiserves bzr directories (repos) and handles security09:39
pygiit seems to define its own ACLTransport ...(or well, at least it has such a class :P)09:39
pygi(bzr 1.13.1, if it makes any difference)09:42
lifelessyes, they probably didn't implement the entire contract, only what they saw used09:42
lifelessbzr 1.13 streams09:42
lifelesswhich means the server will use the streaming transport apis09:42
pygihm, can that be the problem then? I mean I doubt this was written with 1.13 in mind...09:43
pygi(and yes, I know I'm bugging, sorry :))09:44
lifelessI assume so09:44
* pygi goes try with different bzr09:45
pygiguess I'll just have to submit patches if that's the problem:)09:45
pygiit seems to need 1.12...09:48
* pygi tries that09:48
pygilifeless, ok, different problem: bzr: ERROR: Server sent an unexpected error: ('error', 'Operation not supported: append_file')09:55
lifelesspygi: have you used this software before :) - [is it complete :P]10:01
pygilifeless, actually, this is the first time I'm testing it thoroughly :P10:01
pygibut it is supposed to be complete :p10:01
pygidon't worry about it, I'll look into the codebase :)10:06
pygithanks for all the help10:06
=== NEBAP|work2 is now known as Nebap|work
=== Nebap|work is now known as NEBAP|work
CBro2007guys I was trying to understand this error. can someone help?10:57
CBro2007Basically want to get rid of everything in the dir and get a fresh new copy from bzr repository10:58
CBro2007can someone please help? :)10:59
bob2bzr break-lock file:///home/dchoon/dcrepo/11:04
Peng_CBro2007: Check for any bzr process that actually has been running for the last 98 hours. If there aren't any, use "bzr break-lock" -- bah, bob2 is quick.11:04
CBro2007Peng_: Yeah I just ran the bzr break-lock11:05
CBro2007it worked11:05
CBro2007but then I did the "bzr pull --overwrite"11:05
CBro2007and it still kept all the rest of the files in there11:05
Peng_What files?11:05
bob2so you deleted some files11:05
bob2and want them back?11:05
bob2ala 'xvs update'?11:06
CBro2007well basically this developer added new files etc... and his version doesn't work11:06
CBro2007so I suggested overwriting all his local files11:06
bob2that's not an awesome idea11:06
CBro2007well basically want to revert back to what was working well...11:07
CBro2007he has gone ahead and created all these files and ran commands that blurted out lots of stuff that isn't needed11:07
CBro2007its easier for him to checkout the latest repo copy and start from there11:07
bob2so, 'bzr revert' will revert to the last commited version11:07
CBro2007yeah but it might still keep the new stuff?11:08
CBro2007he has not ADDED his new files11:08
bob2then delete them11:08
bob2pull isn't going to delete random un-added files from the working tree11:08
bob2bzr revert ; bzr clean-tree # revert and delete all unadded files11:08
CBro2007says unknown command11:11
bob2it's new11:11
CBro2007clean-tree is an unkown command11:11
bob2alternatively, 'bzr status' then manually delete the files11:11
CBro2007got an older equivalent11:11
bob2or branch from your repository again11:11
CBro2007how bout add and then revert?11:12
CBro2007would that not add all the new files in and then when you revert it gets rid of them all?11:12
LarstiQCBro2007: clean-tree used to be in bzrtools before it moved to bzr core11:17
LarstiQbzr ls --unknown | xargs rm11:17
LarstiQwould also work11:18
bob2as long as there are no spaces in your filenames11:18
LarstiQand no directories, but you get the idea11:18
CBro2007thanks bob211:20
CBro2007thats all good now11:21
CBro2007just a normal delete and then a revert11:21
=== chx_sleeping is now known as chx
Stavroswhy does bzr insist on messing up my tree when all i want to do is push my local changes upstream?13:32
Stavrosit is interfering with the whole "distributed" paradigm13:33
Stavroscan i just push instead of updating on a bound branch?13:34
beunoStavros, yes, but you have to use branches instead of checkouts13:36
beunoyou can use --reconfigure to change a checkout into a branch13:36
Stavrosbeuno: i have a checkout right now, and whenever i do a local commit and then try to update, it messes up my working tree13:37
LarstiQStavros: eh?13:37
Stavrosi just want to push the changes, how can i do that?13:37
LarstiQStavros: could you be more specific as to what happens?13:37
StavrosLarstiQ: i have a bound branch13:37
Stavrosi commit with --local13:37
Stavrosthen i update, and my local working directory gets messed up13:37
LarstiQplease describe 'messed up' a bit more.13:38
james_wLarstiQ: he doesn't want the merge implied by update13:38
Stavrosbzr thinks there are conflicts, but the revision on the remote repo is one earlier than the local one13:38
LarstiQStavros: that is weird13:38
Stavrosso the remote has rev 60, the local rev 61, and it still merges13:38
james_wStavros: why are you doing update? why not just commit?13:38
Stavrosjames_w: i did commit once13:39
Stavrosjames_w: don't i have to update to push them?13:39
LarstiQStavros: are they the same revision though?13:39
StavrosLarstiQ: the local repo has one more revision13:39
james_wStavros: I don't think so13:39
StavrosLarstiQ: i'm the only person working on this, so they never diverge13:39
Stavrosjames_w: hmm13:39
LarstiQStavros: you do update to merge in changes from the master branch13:39
LarstiQStavros: hah, I diverge myself pretty often, but ok :)13:40
StavrosLarstiQ: sure, but isn't bzr supposed to know that there haven't been any?13:40
Stavrosnow, it tries to sort of "revert" to the master branch13:40
Stavrosand gives me conflicts to what i changed13:40
LarstiQStavros: indeed, so I'm rather suprsised at conflicts.13:40
StavrosLarstiQ: well yes, but i don't atm :p13:40
Stavrosnow i have a pending commit, how do i push it upstream?13:40
LarstiQStavros: commit.13:40
Stavroswith a message again?13:40
Stavrosi don't want to commit my local changes, though13:41
LarstiQStavros: yes, or you can be sneaky.13:41
LarstiQStavros: and bzr pull . -r revid:revidoflocaltip13:41
LarstiQStavros: it does sound like maybe a checkout is not the optimal workflow for you though.13:42
Stavrosi just want to do the equivalent of a push but on a bound branch :/13:42
StavrosLarstiQ: why not?13:42
LarstiQ(apart from update pivoting changes when not strictly needed)13:42
StavrosLarstiQ: i don't want to push each time by hand, so a checkout suits me better13:42
LarstiQStavros: judging from this one case, but maybe the rest of what you do suits better13:43
LarstiQStavros: right, ok13:43
LarstiQStavros: let me mock something up and test if that would work for you13:43
Stavrosso what's the best way to just push my changes?13:43
StavrosLarstiQ: can you reproduce the update merge, by the way?13:46
LarstiQStavros: the update merge is normal, but it doesn't produce any conflicts for me13:47
Stavrosi had rev 60, committed 61 locally, changed a line in a file, and that line conflicted on update13:48
* LarstiQ pauses his mockup13:48
LarstiQStavros: I'll find you a relevant bug report about the pending merges pivot first13:49
Stavroshmm ok13:49
Stavrosso it goes, bzr ci, bzr ci --local, change line, bzr up, conflicts13:49
LarstiQah, that is slightly different from what I did, will try it too13:50
* LarstiQ didn't have uncommitted changes prior to the bzr up13:50
LarstiQhmkay, can't find it from bug titles, back to mocking13:53
LarstiQStavros: yeah, a local change gets me a conflict13:58
Stavrosis that normal?13:58
LarstiQI understand why it might happen, it's not ideal.13:59
LarstiQStavros: do you know the revid of the pending merge by chance?14:01
Stavrosit's still in my repo, how do i see it?14:01
LarstiQit's unfortunately harder to get to after the fact14:01
LarstiQStavros: `bzr heads` from bzrtools might help14:01
Stavroshmm, let me install it14:02
LarstiQ`bzr heads --dead` specifically14:02
LarstiQyou can then do `bzr pull . -r revid:<bzr heads discovered revid>`14:03
LarstiQthat will probably give you lots of extra conflicts :/14:03
Stavroswell what good is that then? :P14:03
LarstiQStavros: the revisions are pushed to the master14:04
Stavroswith pull?14:04
LarstiQStavros: yup, it's a bound branch14:04
Stavrosoh right14:04
Stavrosthere are two dead revisions14:05
Stavrosone is five days old14:05
LarstiQyeah, 'dead' revisions are not garbage collected14:06
Stavrosis the other one in my tree?14:06
LarstiQlucikly for us, since we can now recover14:06
LarstiQStavros: it is in your repository, but since it is dead not part of your branch history14:07
Stavroswell that's odd14:07
LarstiQStavros: this happens for example when you use uncommit14:07
Stavroshow did the history progress without it?14:07
Stavrosi didn't14:07
LarstiQStavros: or pull --overwrite14:07
LarstiQor several other ways possibly14:07
LarstiQStavros: history progressed by backtracking from this branch in the revision DAG and setting off in a different direction14:08
Stavrosso what should i do now? pull with the revid?14:10
LarstiQStavros: yes14:10
Stavroswait, am i pulling from my branch to my branch?14:10
LarstiQStavros: yes14:10
Stavrosshould i back up my working tree first?14:10
LarstiQStavros: should not be really needed, but safety first :)14:11
LarstiQStavros: rather than pulling from your branch to your branch, you are pulling from the repository your branch uses14:11
Stavrosthe local one, you mean?14:12
Stavrosor the bound one?14:12
LarstiQStavros: the local one14:12
Stavrosit's pulling14:12
Stavrosa bunch of conflicts again14:14
Stavrosand my tree is ruined :/14:14
LarstiQStavros: well, you can resolve the conflicts14:14
Stavrosalready did14:14
Stavrosbut it should be a simple process :/14:15
Stavrosi don't want my dvcs to get in the way like this14:15
LarstiQStavros: agreed.14:15
Stavrosis there another way to do it?14:15
Stavrosmaybe unbind and push or just push or something?14:15
LarstiQStavros: unbind and push would have worked.14:15
LarstiQStavros: not having local changes at update time would also not have caused conflicts14:15
LarstiQStavros: personally, I don't use checkouts14:16
LarstiQStavros: longer term, this area needs love14:16
LarstiQStavros: imho, the update should not pivot out the local commits if the master is a strict subset14:16
Stavrosyeah :/14:16
LarstiQStavros: that way it wouldn't need to do any merges, hence no conflicts14:17
Stavrosi use checkouts because i update the master branch every time14:17
LarstiQI am very certain this has been discussed in the past, but I can't find a relevant bug atm :/14:17
Stavrosfor backup or other workflow purposes14:17
Stavroshmm :/14:17
LarstiQStavros: maybe you can help me search?14:18
LarstiQand then update the bug/try to get some movement on it14:18
Stavrosdamn, my connection sucks14:19
Stavrosstill loading the bugs page14:20
LarstiQhttps://bugs.edge.launchpad.net/bzr/+bug/175589 is not what I had in mind, but it describes your situation14:21
ubottuLaunchpad bug 175589 in bzr "suggested update when bound branch is out of date does confusing things" [Undecided,Incomplete]14:21
pygilifeless, I fixed the problem, just in case you're interested :p14:22
Stavrosi can't load any pages :/14:23
Stavrosmy connection is the equivalent of dialup14:23
Stavrosoh wait, it's loading14:24
LarstiQStavros: that sounds painful14:24
StavrosLarstiQ: it is :/14:24
Stavrospushes take a minute14:24
Stavrosah, the page loaded14:24
Stavrosshould i comment on that?14:25
LarstiQStavros: I'll comment on it14:26
LarstiQStavros: did I forget anything?14:32
Stavrosi will tell you when it loads :p14:33
Stavrosnope, looks pretty spot on14:34
* LarstiQ subscribed to the bug14:34
LarstiQnow to file one for `bzr st -v --show-ids`14:35
Stavrosdamn, i forgot to subscribe14:41
Stavrosanother two minutes of loading14:41
Stavrospretty multicultural, the subscription list14:42
LarstiQStavros: if needed I can subscribe you14:46
Stavrosi subscribed, thanks14:46
Stavrosit finally loaded14:46
IledenHi! Is there a way to have the .bzr directory in different location of the working tree?15:48
LarstiQIleden: I think the answer is 'no', but I admit that your question isn't entirely clear to me.15:49
Iledenfor example, having tree at /home/ileden/projects/foo/tree-goes-here  and having the .bzr directory for in in /home/ileden/projects/bzrdata/foo/.bzr (or such)15:50
IledenI guess one option would be to always have the project files one step deeper, but a custom location would be mor elegant in a way15:51
Iledenthe problem is, I'd like to sync the working tree with Dropbox, which cannot be told how to ignore the .bzr data dir.15:52
IledenLarstiQ: yeah, I was afraid it's probably impossible.15:54
Iledenthe underlying problem here is that I'm doing developement on three different computers, and want to keep them in sync15:55
LarstiQIleden: and using the regular publishing methods (bzr push/pull/merge) is not an option?15:56
LarstiQ(say, you want to sync uncommitted changes as well)15:57
Iledenand if I'm working on three different projects I'd have to throw all my changes to a network place every time I switch computers15:59
Iledengood scripting might hand that, true, but I still prefer the completely unobtrusive sync Dropbox offers15:59
LarstiQdoes it need to ignore .bzr?15:59
IledenI fear it's probably a bad idea to sync the .bzr dir via dropbox.16:00
LarstiQ`bzr export` also only exports committed revisions, not uncommitted changes16:00
LarstiQIleden: well, a checkout would presumably give you the same style as dropbox16:01
IledenLarstiQ: true, but I would lose the ability to make commits independent of network connection16:02
Iledenwhich is a real issue, since I do a lot of developement in a disconnected environment (namely, the train :) )16:03
LarstiQthere is --local, but it has some issues16:03
Iledenand I also couldn't switch platforms to continue on uncommited changes... athough that's probably not such a big an issue, really.16:04
IledenOh well, placing the files one level deeper than the tree will work fine, just not as elegant, so I think I'll use that.16:05
Iledenhmm, a bigger problem is of course that I can only apply revision history and commits on one of the computers.16:06
Iledenach, it's all just giving me a headache, really :D16:07
* LarstiQ would drop Dropbox16:08
LarstiQbut that's just me16:08
Iledenyeah, it's not really a tool for this situation, I know. :-/16:08
IledenIt's just I love the fact I don't have to do anything to keep the files in sync. Like using a shared online directory, only it's in local path and works offline.16:09
LarstiQIleden: something like the network_manager plugin might help there16:11
Iledenwhat are the issues using --local, by the way?16:12
LarstiQIleden: `bzr update` after local will turn your local commits into pending merges, which if there are uncommitted changes will result in spurious conflicts.16:13
IledenLarstiQ: Ok. Well, thanks for all the information! I'll try to figure out which would be the best approach for me.16:15
LarstiQIleden: you gave me an interesting idea for changing the network_manager plugin anyway :)16:16
goodmamibzr status says I have a pending merge, but bzr merge says "Nothing to do". any ideas?18:22
Necorogoodmami: if you have a pending merge, you already merged ... so "bzr merge" won't do anything18:23
Necoroyou need to commit18:23
goodmamiNecoro, thanks. I was confused because my "bzr pull"s were failing and telling me to do a merge18:24
goodmamii'll try a commit18:24
LarstiQgoodmami: when pull complains the branches are diverged, you bzr merge; (bzr st; bzr diff, etc to make sure everything is ok); bzr commit18:26
goodmamiLarstiQ, thanks. I committed and pushed fine, and all the code seems in order, but it seems to have erased history of a merge from my other developer18:30
goodmami(my other developer's changes were the ones i was having trouble merging into my tree)18:30
LarstiQgoodmami: it sounds like his changes are now merged revisions, and not mainline18:32
LarstiQgoodmami: does `bzr missing` from his branch to the one you just pushed to claim the revisions are actually missing?18:32
goodmamiLarstiQ, yeah perhaps. The repo is hosted by a launchpad team, of which both he and I are members18:32
LarstiQgoodmami: also see bzr log --long (and -n0 if using a new enough bzr)18:32
LarstiQgoodmami: the launchpad web interface doesn't show all revisions, just the mainline ones.18:33
LarstiQgoodmami: lp:glot?18:34
goodmamioh ok, i see his messages in the log file. they are under (indented in) my merge18:34
goodmamiLarstiQ, yes18:34
goodmamilaunchpad did show his changes until i did the last push, so i figured his were mainline18:34
LarstiQgoodmami: when you merged his changes and then committed, you reordered the mainline18:35
goodmamiLarstiQ, oh. hm. i guess that can happen, huh.18:35
LarstiQgoodmami: it can happen. It is indeed not the recommended workflow.18:35
goodmamiLarstiQ, how do I avoid this in the future? should only one person do pushes to the mainline?18:36
LarstiQgoodmami: the trick is to merge into the trunk, not merge the trunk into your branch and then push it over trunk18:37
LarstiQgoodmami: say you have ~/src/glot/trunk and ~/src/glot/mami18:37
LarstiQgoodmami: the first is a mirror of lp:glot, and the second is where you committed your revision 9, then discovered the other Michael had pushed diverging changes to lp:glot18:38
LarstiQgoodmami: you've now probably done, from ~/src/glot/mami; bzr pull (lp:glot) -> message about divergance; bzr merge; bzr ci; bzr push18:38
LarstiQgoodmami: if instead of that you did, cd ~/src/glot/trunk; bzr pull; bzr merge ../mami; bzr ci; bzr push; cd ../mami; bzr pull18:39
LarstiQgoodmami: then his changes would have the same revnos they had (still on the mainline)18:39
goodmamiLarstiQ, I see what you mean, but I was working in trunk (probably not the best idea)18:40
LarstiQgoodmami: and then your changes would not be shown by the launchpad web interface18:40
goodmamiLarstiQ, I had some changes that i committed, and when i pushed it said I didn't have an up to date tree or something18:40
LarstiQgoodmami: right18:40
goodmamiLarstiQ, so I think I did a pull and a merge18:41
* LarstiQ nods18:41
LarstiQgoodmami: there isn't anything technically wrong with how you did things, his changes are still present.18:41
LarstiQgoodmami: it is just presenting a different view on history.18:41
goodmamiLarstiQ, it said there was something wrong in the file from my other dev, so i tried reverting it, then tried to throw away my changes and only use his18:42
LarstiQwhich I admit us humans aren't always comfortable with18:42
LarstiQgoodmami: it had a conflict?18:42
goodmamiLarstiQ, great, now I'm a historical revisionist... ;)18:42
LarstiQgoodmami: only the victors get to rewrite history ;)18:42
goodmamiLarstiQ, it didn't have a conflict, but it complained about it, so I assumed there was a conflict18:42
goodmamiLarstiQ, so... I win?18:42
goodmamiLarstiQ, anyway, I'll be more careful about that now. thanks for the help18:43
LarstiQgoodmami: in the sense of determing which revisions are the mainline, yes, you just won.18:43
LarstiQbzr has an option to disable reordering the mainline, I'm not sure if launchpad can support that too18:43
goodmamiLarstiQ, well hopefully we won't come across this again.18:44
LarstiQ(dredged up from `bzr help configuration`)18:44
goodmamiooh, i'll go check that out18:45
LarstiQgoodmami: please do :)18:45
LarstiQfeedback welcome18:45
goodmamithanks again18:45
stbuehlerwhat does it mean when i get "conflicting tags" in a "bzr push" to a svn repository (we migrated to a new server, 32 -> 64 bit) ?20:19
LarstiQno other changes to the svn repo?20:22
LarstiQno editing of the tags on the bzr side?20:22
stbuehleri don't know for sure, but i don't thinks o20:31
LarstiQstbuehler: then my ideas are depleted and you'll have to ask jelmer20:33
stbuehlerany simpler way restoring this than rebranching it? i do not really care about my bzr history, i use bzr just as a frontend to svn20:33
LarstiQstbuehler: does the push actually fail, or is it just a message? I suspect the latter.20:34
stbuehlerjust a message20:35
stbuehlerbut i don't like it :)20:35
LarstiQstbuehler: does it repeat on later pushes?20:37
LarstiQstbuehler: and yes, it should go away after rebranching20:37
LarstiQstbuehler: I'm not too well versed in tags, but if you can find out what (bzr-)svn thinks the tags are, you could edit the tags file by hand20:38
stbuehleri deleted some tags and pushed again -> no warning for them. bzr pull, tags reappeared, and with the next push the warning came back20:47
LarstiQstbuehler: ok. Have you looked through open bzr(-svn) bugs on tags?20:51
gotgenesI'm trying to install bzr to my home directory on a red hat machine; I got the error "ImportError: No module named _md5" What's supposed to provide that module?21:03
LarstiQgotgenes: what version of python and bzr are you using?21:03
gotgeneslooks like python 2.5.1 installed to /usr/local21:03
gotgenesbzr 1.13.1 from source21:04
LarstiQgotgenes: can you pastebin the backtrace?21:04
gotgenesLarstiQ: Sure21:04
gotgenesone sec21:04
LarstiQgotgenes: note that you can run bzr from source, no installation needed21:04
LarstiQ(running make is still a good idea for more performance)21:05
gotgenesLarstiQ: http://rafb.net/p/yXkGrD79.html21:06
LarstiQgotgenes: that looks like your python install is broken.21:07
LarstiQgotgenes: or at the very least doesn't contain the modules one expects from stdlib.21:08
LarstiQgotgenes: is this a python2.5-minimal package or somesuch?21:08
gotgenesLarstiQ: Possibly. I'm not the sysadmin for that box, unfortunately.21:08
gotgenesLarstiQ: Quite likely.21:08
gotgenesSupposedly it was downloaded from source.21:08
LarstiQgotgenes: python -c 'from hashlib import md5' breaks, right? Does python -c 'import md5' fail as well?21:11
gotgenesLarstiQ: Yes, I just ran that.21:11
LarstiQgotgenes: if so, I'd bug the admin asking for a working python install.21:11
gotgenesLarstiQ: It seems I'll need to.21:12
LarstiQgotgenes: bzr does really need that to operate, is installing your own copy of python an option in the mean time?21:12
gotgenesLarstiQ: Sure, into my home directory21:12
gotgenesSuppose that's not too hard to do21:12
gotgenesLarstiQ: installed Python to the home dir and bazaar installed fine after21:43
LarstiQgotgenes: cool21:45
gotgenesThanks for your help.21:47
jmlI was looking at bug 351686, and wondering whether it's even possible with Bazaar23:55
ubottuLaunchpad bug 351686 in launchpad-bazaar "Merge proposal diffs should use -p option" [Undecided,New] https://launchpad.net/bugs/35168623:55
lifelesssmall matter of code23:58
lifeless-p is actually a regex search up from the change region23:58
lifelesswe support external diff options too if you're invoking diff23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!