=== bob2 is now known as Guest19481 | ||
luke-jr | bzr diff ../server/e/HEAD/ -c 64 | patch -p0 | 00:47 |
---|---|---|
luke-jr | why does that work, yet bzr merge is too stupid to handle it? :/ | 00:47 |
luke-jr | fuzz 2? | 00:49 |
RAOF | luke-jr: Answering that would requrire the message bzr gives as the reason it can't merge. | 00:50 |
luke-jr | it just does conflicts galore | 00:50 |
luke-jr | I'm merging lp:moo/lambdamoo-1.8 updates into lp:~luke-jr/moo/db_options | 00:51 |
RAOF | Hm. Not really sure. | 00:56 |
lifeless | luke-jr: does it detect a criss-cross merge? | 01:06 |
luke-jr | lifeless: there is no criss-cross, no | 01:06 |
luke-jr | db_options has and never will be merged into lambdamoo | 01:07 |
lifeless | luke-jr: its odd that it is conflicting | 01:09 |
lifeless | what type of conflicts is it giving? | 01:10 |
luke-jr | the MERGE-SOURCE side is trying to add about 500 lines of code that was removed in the branch | 01:10 |
lifeless | you could try --weave | 01:12 |
luke-jr | haha. no. | 01:12 |
luke-jr | weave is evil | 01:13 |
lifeless | so 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-jr | correct | 01:16 |
luke-jr | trunk is a CVS import, if that is at all relevant | 01:16 |
luke-jr | branch was created from a tag in the bzr import | 01:16 |
luke-jr | I need to manipulate file-ids. Any advice? | 01:22 |
lifeless | why do you need to do that? | 01:28 |
luke-jr | telling Bazaar about a rename | 01:29 |
lifeless | I 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-jr | long after the fact | 01:29 |
lifeless | bzr mv --after | 01:29 |
luke-jr | it wasn't | 01:29 |
luke-jr | lifeless: long after, meaning the commit is 50 revisions ago | 01:29 |
lifeless | re the conflicts - in which case please file a bug | 01:29 |
lifeless | luke-jr: bzr rm foo --keep; bzr add --file-ids-from [place that has the file] foo | 01:29 |
lifeless | luke-jr: also --weave isn't evil, its good - mysql use it all the time to get massively less conflicts | 01:30 |
luke-jr | hmm | 01:30 |
luke-jr | --weave reduces conflicts, sure, but often it duplicates code | 01:30 |
lifeless | does it? I haven't seen that. That would be a bug IMO | 01:31 |
luke-jr | O.o | 01:31 |
lifeless | basically, feel free to file bugs on merge logic | 01:31 |
lifeless | some will be things we can't easily fix without throwing other things out | 01:31 |
lifeless | but there is lots of room to improve | 01:31 |
luke-jr | the problem-causing merges seem to trigger patch to say "with fuzz 2" | 01:32 |
luke-jr | I can only presume that's related | 01:32 |
BasicOSX | getting only 8kB from LP everything else fast | 01:35 |
luke-jr | lifeless: any way I can ensure I'm not about to totally screw up my branch? XD | 01:37 |
luke-jr | bzr status is giving me some funky output ;/ | 01:37 |
luke-jr | added: db_objects.c | 01:37 |
luke-jr | renamed: db_objects.c => db_save_objects.c | 01:38 |
luke-jr | modified: db_save_objects.c | 01:38 |
luke-jr | does that make sense? :/ | 01:38 |
lifeless | sure | 01:39 |
lifeless | it says that db_objects was modified and renamed | 01:39 |
lifeless | and that you have added a new fiel db_objects.c | 01:39 |
luke-jr | ok | 01:39 |
luke-jr | sigh | 01:40 |
luke-jr | trying to tie these merge trees together is a pain | 01:40 |
=== Guest19481 is now known as bob2 | ||
chx | how do i get my working tree into where it was before 9841 was committed? | 04:43 |
LeoNerd | bzr revert -r9840 | 04:43 |
chx | oh | 04:43 |
LeoNerd | Or.. more accurately, something like bzr revert -rparent:9841 but that probably comes down to 9840 anyway | 04:43 |
chx | i thought revert was only for reverting changes since last commit. | 04:43 |
chx | my bad. | 04:43 |
LeoNerd | revert puts it back to the state at some commit.. by default the most recent... but -r can pick a different one | 04:44 |
luke-jr | what does -rparent do for merges? :p | 04:55 |
Peng_ | Hmm, it's "before:", and the help doesn't say. | 04:57 |
vinc456 | can i reload my bzr.conf file? | 04:59 |
vinc456 | i've made an edit but the changes don't seem to take effect | 05:00 |
Peng_ | bzr.conf? | 05:03 |
vinc456 | sorry branch.conf | 05:03 |
Peng_ | The changes don't take effect...where? There's nothing to reload | 05:08 |
vinc456 | well i defined the alias from the tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html | 05:09 |
vinc456 | but if i try something like 'bzr ll' i get an unknown command error | 05:10 |
vinc456 | i thought i might have to run some sort of source command, the way i do when i edit .bashrc or something | 05:10 |
Peng_ | vinc456: Maybe you have to set that in ~/.bazaar/bazaar.conf. | 05:12 |
vinc456 | Peng_: i set ~/.bzr/branch/branch.conf | 05:15 |
vinc456 | anyways it's not a big deal | 05:16 |
vinc456 | it'll probably work fine once the next time i reboot | 05:16 |
Peng_ | vinc456: Um, no it won't. | 05:16 |
Peng_ | vinc456: ~/.bazaar/bazaar.conf. | 05:16 |
vinc456 | Peng_: ah ok, i was confused | 05:19 |
vinc456 | thanks | 05:19 |
seb_kuzminsky | does cherrypicking lose merge tracking? | 05:45 |
seb_kuzminsky | i 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_kuzminsky | that's on bzr 1.11 | 05:46 |
Peng_ | seb_kuzminsky: That's correct. Which is why we try to avoid cherrypicking. :D | 05:48 |
seb_kuzminsky | ok thanks Peng | 05:55 |
Peng_ | Sorry. :\ | 05:56 |
BasicOSX | make check-dist-tarball failing on 1.14rc1 release. Anyone able to look at bug 355454 ? | 06:00 |
ubottu | Launchpad bug 355454 in bzr "$ make check-dist-tarball failure" [Undecided,New] https://launchpad.net/bugs/355454 | 06:00 |
Peng_ | I don't think Unicode issues like that are new. | 06:01 |
BasicOSX | wasn't an issue 1.13 | 06:02 |
Peng_ | Oh. Never mind then. :D | 06:03 |
BasicOSX | interesting bzr selftest passes | 06: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 |
BasicOSX | Ahh, how it make through PQM? I thought the multiple LANG stuff got put into PQM? | 06:17 |
* Peng_ shrugs | 06:18 | |
BasicOSX | less shrugs, more answer! :-P | 06: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 | ||
glyph | I'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 |
glyph | Is there a way I can fix up that history? | 06:57 |
Peng_ | Pretty much no. | 06:59 |
glyph | Peng_: Hmm... I guess I should rebase from zero then? | 07:00 |
luke-jr | I used cvsps-import to do the initial migration of a CVS upstream to Bzr; how do I get syncs from CVS in? | 07:00 |
spiv | glyph: editing a fast-import dump might be relatively painless, if you really care. (does it really matter?) | 07:02 |
glyph | spiv: 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 |
jkakar | glyph: I trust GPG signed commits as a verification method much more than an email address. | 07:39 |
glyph | jkakar: These commits weren't signed either :) | 07:47 |
glyph | jkakar: Can I go back and sign them? | 07:47 |
bob2 | bzr sign-my-commits | 07:48 |
glyph | bob2: Huh | 07:56 |
glyph | and then if I push somewhere, signatures for old revisions will be published? | 07:56 |
bob2 | dunno | 07:56 |
bob2 | also not sure what it'll do wrt your whoami having changed - you might need to temporarily change that back | 07:56 |
glyph | bob2: It looks like I can pass a committer on the commandline | 07:57 |
lifeless | glyph: 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 open | 08:09 |
lifeless | glyph: and possibly a hidden command | 08:09 |
glyph | I guess for now I will not worry about this | 08:10 |
jkakar | glyph: I have this in my ~/.bazaar/locations.conf, which causes all my commits to be GPG signed: http://paste.ubuntu.com/144726/ | 09:01 |
glyph | jkakar: I'll be adding something like that soon, as soon as I figure out how seahorse-agent works | 09:02 |
glyph | (I don't like having gpg private keys on my hard drive) | 09:02 |
jkakar | Yeah, that's probably a good call. | 09:02 |
jkakar | I was doing the SSH+GPG key on a USB stick thing for a while... | 09:02 |
glyph | jkakar: You stopped? | 09:03 |
pygi | ok, folks, got a tiny problem with push | 09:03 |
jkakar | but 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 |
pygi | http://slexy.org/view/s21qWJI3Rj | 09:03 |
jkakar | Though, 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 |
jkakar | glyph: So yeah, I stopped. | 09:04 |
jkakar | I'm probably not paranoid enough, oh well. Ignorance really is bliss. ;) | 09:04 |
kizzo | How 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 |
jkakar | kizzo: rm `bzr added` | 09:06 |
lifeless | kizzo: or 'bzr revert' the added files | 09:06 |
kizzo | jkakar: That looks like it would actually delete the files from my disk, huh? | 09:06 |
kizzo | The first one. | 09:07 |
jkakar | kizzo: It will, yes. | 09:07 |
kizzo | Oh ok, so revert is probably what I would like to happen then. | 09:07 |
kizzo | Cool. | 09:07 |
kizzo | Thanks. | 09:08 |
pygi | :-/ | 09:09 |
lifeless | pywhats wrong? | 09:10 |
lifeless | pygi: ^ | 09:10 |
pygi | lifeless, If I knew that'd be good :p | 09:11 |
pygi | probably something with the server :P | 09:11 |
pygi | lifeless, http://slexy.org/view/s21qWJI3Rj | 09:11 |
lifeless | oh, I can't browse right now | 09:11 |
pygi | :P | 09:13 |
pygi | basically, I can't push :D | 09:13 |
lifeless | do you get an error? | 09:13 |
pygi | bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'Operation not supported: open_write_stream') | 09:13 |
lifeless | that sounds like you have an _extremely_ old server | 09:13 |
lifeless | or hmm | 09:13 |
lifeless | perhaps its backed onto a readonly transport | 09:13 |
lifeless | the latter is more likely I think | 09:14 |
* pygi is pretty sure he configured rw privs | 09:14 | |
pygi | it might be that security subsystem of this server is a bit wonky | 09:15 |
pygi | its still pretty fresh | 09:15 |
lifeless | are you pushing to bzr+ssh/bzr/bzr+http? | 09:15 |
pygi | bzr+http | 09:15 |
lifeless | what backing transport did you give it in your glue code? | 09:15 |
pygi | hmm | 09:16 |
pygi | how do you mean? | 09:16 |
lifeless | well to setup a bzr+http server you need some wsgi glue | 09:17 |
lifeless | and in that you tell it where the server backend is | 09:18 |
lifeless | what url did you use in there | 09:18 |
pygi | yup, moment :p | 09:18 |
pygi | local_url = wsgi.local_path_to_url(root) ? | 09:19 |
pygi | I mean, I can branch pretty fine, its probably something in the security code or something :-/ | 09:20 |
lifeless | no | 09:20 |
pygi | (not of bzr security code, but of that wsgi glue/security glue code that you say :) | 09:21 |
lifeless | did you follow the howto ? | 09:22 |
lifeless | doc/en/user-guide/http_smart_server.txt | 09:22 |
pygi | actually, no, purely because I use a custom-written server (clue-bzrsever) | 09:23 |
lifeless | ok | 09:23 |
lifeless | well | 09:23 |
lifeless | cross reference the howto | 09:23 |
lifeless | if when you start the backend server you are passing in an http transport its fundamentally wrong | 09:23 |
lifeless | from bzrlib.transport.http import wsgi | 09: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 |
lifeless | is the key bit | 09:24 |
lifeless | root needs to be your on disk path to the root you want to serve out | 09:24 |
lifeless | and you'll want readonly=False :) | 09:24 |
pygi | :) | 09:24 |
pygi | thanks, I'll see what I can do | 09:26 |
pygi | hm, ok, readonly IS false | 09:29 |
pygi | is this correct: write = ['mkdir', 'put_file', 'delete', 'rename', 'rmdir', 'append_file', ] ? | 09:30 |
lifeless | that looks like something to do with your custom server | 09:30 |
lifeless | its certainly not an accurate list of what bzr uses to push, if thats what you're asking | 09:30 |
pygi | can that be the problem? | 09:30 |
lifeless | I don't know, I'm guessing at things here | 09:32 |
lifeless | what does this custom server do? | 09:32 |
lifeless | how does it hook into bzr? | 09:32 |
pygi | using bzrlib | 09:32 |
lifeless | I mean, it could implement the protocol, or it might subclass the request dispatcher, or handler lookup, or decorate the backing transport, or something else again | 09:33 |
lifeless | I have no idea about it, today is the first time I heard of it | 09:33 |
lifeless | and without knowing a fair bit more I can't offer good advice :( | 09:34 |
pygi | let me check | 09:34 |
lifeless | I 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 transport | 09:35 |
lifeless | in which case giving it a more complete list would be a good idea:) | 09:35 |
pygi | could you point me to location where I can find more complete list? :) | 09:36 |
lifeless | pydoc bzrlib.transport.Transport is the base class for all transports | 09:36 |
lifeless | it defines the public api | 09:36 |
lifeless | pygi: what does the custom server do for you? | 09:38 |
pygi | serves bzr directories (repos) and handles security | 09:39 |
pygi | it 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 |
lifeless | yes, they probably didn't implement the entire contract, only what they saw used | 09:42 |
lifeless | bzr 1.13 streams | 09:42 |
lifeless | which means the server will use the streaming transport apis | 09:42 |
pygi | hm, 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 |
lifeless | I assume so | 09:44 |
* pygi goes try with different bzr | 09:45 | |
pygi | guess I'll just have to submit patches if that's the problem:) | 09:45 |
pygi | it seems to need 1.12... | 09:48 |
* pygi tries that | 09:48 | |
pygi | lifeless, ok, different problem: bzr: ERROR: Server sent an unexpected error: ('error', 'Operation not supported: append_file') | 09:55 |
pygi | o.O | 09:55 |
lifeless | pygi: have you used this software before :) - [is it complete :P] | 10:01 |
pygi | lifeless, actually, this is the first time I'm testing it thoroughly :P | 10:01 |
pygi | but it is supposed to be complete :p | 10:01 |
pygi | don't worry about it, I'll look into the codebase :) | 10:06 |
pygi | thanks for all the help | 10:06 |
lifeless | np | 10:07 |
=== NEBAP|work2 is now known as Nebap|work | ||
=== Nebap|work is now known as NEBAP|work | ||
CBro2007 | http://www.pastie.org/437377 | 10:57 |
CBro2007 | guys | 10:57 |
CBro2007 | guys I was trying to understand this error. can someone help? | 10:57 |
CBro2007 | http://www.pastie.org/437377 | 10:58 |
CBro2007 | Basically want to get rid of everything in the dir and get a fresh new copy from bzr repository | 10:58 |
CBro2007 | can someone please help? :) | 10:59 |
bob2 | bzr 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 |
CBro2007 | Peng_: Yeah I just ran the bzr break-lock | 11:05 |
CBro2007 | it worked | 11:05 |
CBro2007 | but then I did the "bzr pull --overwrite" | 11:05 |
CBro2007 | and it still kept all the rest of the files in there | 11:05 |
Peng_ | Uh-huh...? | 11:05 |
Peng_ | What files? | 11:05 |
bob2 | so you deleted some files | 11:05 |
bob2 | and want them back? | 11:05 |
bob2 | ala 'xvs update'? | 11:06 |
CBro2007 | well basically this developer added new files etc... and his version doesn't work | 11:06 |
CBro2007 | so I suggested overwriting all his local files | 11:06 |
bob2 | that's not an awesome idea | 11:06 |
CBro2007 | well basically want to revert back to what was working well... | 11:07 |
CBro2007 | he has gone ahead and created all these files and ran commands that blurted out lots of stuff that isn't needed | 11:07 |
CBro2007 | its easier for him to checkout the latest repo copy and start from there | 11:07 |
bob2 | so, 'bzr revert' will revert to the last commited version | 11:07 |
CBro2007 | yeah but it might still keep the new stuff? | 11:08 |
CBro2007 | he has not ADDED his new files | 11:08 |
bob2 | then delete them | 11:08 |
bob2 | pull isn't going to delete random un-added files from the working tree | 11:08 |
bob2 | bzr revert ; bzr clean-tree # revert and delete all unadded files | 11:08 |
CBro2007 | says unknown command | 11:11 |
bob2 | it's new | 11:11 |
CBro2007 | clean-tree is an unkown command | 11:11 |
bob2 | alternatively, 'bzr status' then manually delete the files | 11:11 |
CBro2007 | got an older equivalent | 11:11 |
bob2 | or branch from your repository again | 11:11 |
CBro2007 | how bout add and then revert? | 11:12 |
CBro2007 | would that not add all the new files in and then when you revert it gets rid of them all? | 11:12 |
LarstiQ | CBro2007: clean-tree used to be in bzrtools before it moved to bzr core | 11:17 |
CBro2007 | ok | 11:17 |
LarstiQ | bzr ls --unknown | xargs rm | 11:17 |
LarstiQ | would also work | 11:18 |
bob2 | as long as there are no spaces in your filenames | 11:18 |
LarstiQ | and no directories, but you get the idea | 11:18 |
CBro2007 | thanks bob2 | 11:20 |
CBro2007 | thats all good now | 11:21 |
CBro2007 | just a normal delete and then a revert | 11:21 |
=== chx_sleeping is now known as chx | ||
Stavros | why does bzr insist on messing up my tree when all i want to do is push my local changes upstream? | 13:32 |
Stavros | it is interfering with the whole "distributed" paradigm | 13:33 |
Stavros | can i just push instead of updating on a bound branch? | 13:34 |
beuno | Stavros, yes, but you have to use branches instead of checkouts | 13:36 |
beuno | you can use --reconfigure to change a checkout into a branch | 13:36 |
Stavros | beuno: i have a checkout right now, and whenever i do a local commit and then try to update, it messes up my working tree | 13:37 |
LarstiQ | Stavros: eh? | 13:37 |
Stavros | i just want to push the changes, how can i do that? | 13:37 |
LarstiQ | Stavros: could you be more specific as to what happens? | 13:37 |
Stavros | LarstiQ: i have a bound branch | 13:37 |
Stavros | i commit with --local | 13:37 |
Stavros | then i update, and my local working directory gets messed up | 13:37 |
LarstiQ | please describe 'messed up' a bit more. | 13:38 |
james_w | LarstiQ: he doesn't want the merge implied by update | 13:38 |
Stavros | bzr thinks there are conflicts, but the revision on the remote repo is one earlier than the local one | 13:38 |
LarstiQ | Stavros: that is weird | 13:38 |
Stavros | so the remote has rev 60, the local rev 61, and it still merges | 13:38 |
james_w | Stavros: why are you doing update? why not just commit? | 13:38 |
Stavros | james_w: i did commit once | 13:39 |
Stavros | james_w: don't i have to update to push them? | 13:39 |
LarstiQ | Stavros: are they the same revision though? | 13:39 |
Stavros | LarstiQ: the local repo has one more revision | 13:39 |
james_w | Stavros: I don't think so | 13:39 |
Stavros | LarstiQ: i'm the only person working on this, so they never diverge | 13:39 |
Stavros | james_w: hmm | 13:39 |
LarstiQ | Stavros: you do update to merge in changes from the master branch | 13:39 |
LarstiQ | Stavros: hah, I diverge myself pretty often, but ok :) | 13:40 |
Stavros | LarstiQ: sure, but isn't bzr supposed to know that there haven't been any? | 13:40 |
Stavros | now, it tries to sort of "revert" to the master branch | 13:40 |
Stavros | and gives me conflicts to what i changed | 13:40 |
LarstiQ | Stavros: indeed, so I'm rather suprsised at conflicts. | 13:40 |
Stavros | LarstiQ: well yes, but i don't atm :p | 13:40 |
Stavros | now i have a pending commit, how do i push it upstream? | 13:40 |
LarstiQ | Stavros: commit. | 13:40 |
Stavros | with a message again? | 13:40 |
Stavros | i don't want to commit my local changes, though | 13:41 |
LarstiQ | Stavros: yes, or you can be sneaky. | 13:41 |
Stavros | hmm | 13:41 |
LarstiQ | Stavros: and bzr pull . -r revid:revidoflocaltip | 13:41 |
LarstiQ | Stavros: it does sound like maybe a checkout is not the optimal workflow for you though. | 13:42 |
Stavros | i just want to do the equivalent of a push but on a bound branch :/ | 13:42 |
Stavros | LarstiQ: why not? | 13:42 |
LarstiQ | (apart from update pivoting changes when not strictly needed) | 13:42 |
Stavros | LarstiQ: i don't want to push each time by hand, so a checkout suits me better | 13:42 |
LarstiQ | Stavros: judging from this one case, but maybe the rest of what you do suits better | 13:43 |
LarstiQ | Stavros: right, ok | 13:43 |
LarstiQ | Stavros: let me mock something up and test if that would work for you | 13:43 |
Stavros | so what's the best way to just push my changes? | 13:43 |
Stavros | thanks | 13:43 |
Stavros | LarstiQ: can you reproduce the update merge, by the way? | 13:46 |
LarstiQ | Stavros: the update merge is normal, but it doesn't produce any conflicts for me | 13:47 |
Stavros | hmm | 13:47 |
Stavros | i had rev 60, committed 61 locally, changed a line in a file, and that line conflicted on update | 13:48 |
* LarstiQ pauses his mockup | 13:48 | |
LarstiQ | Stavros: I'll find you a relevant bug report about the pending merges pivot first | 13:49 |
Stavros | hmm ok | 13:49 |
Stavros | so it goes, bzr ci, bzr ci --local, change line, bzr up, conflicts | 13:49 |
LarstiQ | ah, that is slightly different from what I did, will try it too | 13:50 |
* LarstiQ didn't have uncommitted changes prior to the bzr up | 13:50 | |
Stavros | ah | 13:50 |
LarstiQ | hmkay, can't find it from bug titles, back to mocking | 13:53 |
LarstiQ | Stavros: yeah, a local change gets me a conflict | 13:58 |
Stavros | is that normal? | 13:58 |
LarstiQ | I understand why it might happen, it's not ideal. | 13:59 |
Stavros | hmm | 14:00 |
LarstiQ | Stavros: do you know the revid of the pending merge by chance? | 14:01 |
Stavros | it's still in my repo, how do i see it? | 14:01 |
LarstiQ | it's unfortunately harder to get to after the fact | 14:01 |
LarstiQ | Stavros: `bzr heads` from bzrtools might help | 14:01 |
Stavros | hmm, let me install it | 14:02 |
LarstiQ | `bzr heads --dead` specifically | 14:02 |
LarstiQ | you can then do `bzr pull . -r revid:<bzr heads discovered revid>` | 14:03 |
LarstiQ | that will probably give you lots of extra conflicts :/ | 14:03 |
Stavros | well what good is that then? :P | 14:03 |
LarstiQ | Stavros: the revisions are pushed to the master | 14:04 |
Stavros | ah | 14:04 |
Stavros | with pull? | 14:04 |
LarstiQ | Stavros: yup, it's a bound branch | 14:04 |
Stavros | oh right | 14:04 |
Stavros | sec | 14:04 |
Stavros | there are two dead revisions | 14:05 |
Stavros | one is five days old | 14:05 |
Stavros | wth | 14:05 |
LarstiQ | yeah, 'dead' revisions are not garbage collected | 14:06 |
Stavros | ah | 14:06 |
Stavros | is the other one in my tree? | 14:06 |
LarstiQ | lucikly for us, since we can now recover | 14:06 |
LarstiQ | Stavros: it is in your repository, but since it is dead not part of your branch history | 14:07 |
Stavros | hmm | 14:07 |
Stavros | well that's odd | 14:07 |
LarstiQ | Stavros: this happens for example when you use uncommit | 14:07 |
Stavros | how did the history progress without it? | 14:07 |
Stavros | i didn't | 14:07 |
LarstiQ | Stavros: or pull --overwrite | 14:07 |
LarstiQ | or several other ways possibly | 14:07 |
LarstiQ | Stavros: history progressed by backtracking from this branch in the revision DAG and setting off in a different direction | 14:08 |
Stavros | ah | 14:10 |
Stavros | so what should i do now? pull with the revid? | 14:10 |
LarstiQ | Stavros: yes | 14:10 |
Stavros | wait, am i pulling from my branch to my branch? | 14:10 |
LarstiQ | Stavros: yes | 14:10 |
Stavros | should i back up my working tree first? | 14:10 |
LarstiQ | Stavros: should not be really needed, but safety first :) | 14:11 |
LarstiQ | Stavros: rather than pulling from your branch to your branch, you are pulling from the repository your branch uses | 14:11 |
Stavros | the local one, you mean? | 14:12 |
Stavros | or the bound one? | 14:12 |
LarstiQ | Stavros: the local one | 14:12 |
Stavros | ah | 14:12 |
Stavros | it's pulling | 14:12 |
Stavros | a bunch of conflicts again | 14:14 |
Stavros | and my tree is ruined :/ | 14:14 |
LarstiQ | Stavros: well, you can resolve the conflicts | 14:14 |
Stavros | already did | 14:14 |
Stavros | but it should be a simple process :/ | 14:15 |
Stavros | i don't want my dvcs to get in the way like this | 14:15 |
LarstiQ | Stavros: agreed. | 14:15 |
Stavros | is there another way to do it? | 14:15 |
Stavros | maybe unbind and push or just push or something? | 14:15 |
LarstiQ | Stavros: unbind and push would have worked. | 14:15 |
LarstiQ | Stavros: not having local changes at update time would also not have caused conflicts | 14:15 |
LarstiQ | Stavros: personally, I don't use checkouts | 14:16 |
LarstiQ | Stavros: longer term, this area needs love | 14:16 |
LarstiQ | Stavros: imho, the update should not pivot out the local commits if the master is a strict subset | 14:16 |
Stavros | yeah :/ | 14:16 |
LarstiQ | Stavros: that way it wouldn't need to do any merges, hence no conflicts | 14:17 |
Stavros | agreed | 14:17 |
Stavros | i use checkouts because i update the master branch every time | 14:17 |
LarstiQ | I am very certain this has been discussed in the past, but I can't find a relevant bug atm :/ | 14:17 |
Stavros | for backup or other workflow purposes | 14:17 |
Stavros | hmm :/ | 14:17 |
LarstiQ | Stavros: maybe you can help me search? | 14:18 |
LarstiQ | and then update the bug/try to get some movement on it | 14:18 |
Stavros | sure | 14:18 |
Stavros | damn, my connection sucks | 14:19 |
Stavros | still loading the bugs page | 14:20 |
LarstiQ | https://bugs.edge.launchpad.net/bzr/+bug/175589 is not what I had in mind, but it describes your situation | 14:21 |
ubottu | Launchpad bug 175589 in bzr "suggested update when bound branch is out of date does confusing things" [Undecided,Incomplete] | 14:21 |
pygi | lifeless, I fixed the problem, just in case you're interested :p | 14:22 |
Stavros | i can't load any pages :/ | 14:23 |
Stavros | my connection is the equivalent of dialup | 14:23 |
Stavros | oh wait, it's loading | 14:24 |
LarstiQ | Stavros: that sounds painful | 14:24 |
Stavros | LarstiQ: it is :/ | 14:24 |
Stavros | pushes take a minute | 14:24 |
Stavros | ah, the page loaded | 14:24 |
Stavros | should i comment on that? | 14:25 |
LarstiQ | Stavros: I'll comment on it | 14:26 |
Stavros | thanks | 14:26 |
LarstiQ | Stavros: did I forget anything? | 14:32 |
Stavros | i will tell you when it loads :p | 14:33 |
Stavros | nope, looks pretty spot on | 14:34 |
* LarstiQ subscribed to the bug | 14:34 | |
LarstiQ | now to file one for `bzr st -v --show-ids` | 14:35 |
Stavros | damn, i forgot to subscribe | 14:41 |
Stavros | another two minutes of loading | 14:41 |
Stavros | pretty multicultural, the subscription list | 14:42 |
LarstiQ | Stavros: if needed I can subscribe you | 14:46 |
Stavros | i subscribed, thanks | 14:46 |
Stavros | it finally loaded | 14:46 |
Ileden | Hi! Is there a way to have the .bzr directory in different location of the working tree? | 15:48 |
LarstiQ | Ileden: I think the answer is 'no', but I admit that your question isn't entirely clear to me. | 15:49 |
Ileden | for 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 |
Ileden | I guess one option would be to always have the project files one step deeper, but a custom location would be mor elegant in a way | 15:51 |
Ileden | the 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 |
Ileden | LarstiQ: yeah, I was afraid it's probably impossible. | 15:54 |
Ileden | the underlying problem here is that I'm doing developement on three different computers, and want to keep them in sync | 15:55 |
LarstiQ | Ileden: 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 |
Ileden | yes | 15:58 |
Ileden | and if I'm working on three different projects I'd have to throw all my changes to a network place every time I switch computers | 15:59 |
Ileden | good scripting might hand that, true, but I still prefer the completely unobtrusive sync Dropbox offers | 15:59 |
LarstiQ | does it need to ignore .bzr? | 15:59 |
Ileden | I 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 changes | 16:00 |
LarstiQ | Ileden: well, a checkout would presumably give you the same style as dropbox | 16:01 |
Ileden | LarstiQ: true, but I would lose the ability to make commits independent of network connection | 16:02 |
Ileden | which is a real issue, since I do a lot of developement in a disconnected environment (namely, the train :) ) | 16:03 |
LarstiQ | right | 16:03 |
LarstiQ | there is --local, but it has some issues | 16:03 |
Ileden | and I also couldn't switch platforms to continue on uncommited changes... athough that's probably not such a big an issue, really. | 16:04 |
Ileden | Oh 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 |
Ileden | hmm, a bigger problem is of course that I can only apply revision history and commits on one of the computers. | 16:06 |
Ileden | ach, it's all just giving me a headache, really :D | 16:07 |
* LarstiQ would drop Dropbox | 16:08 | |
LarstiQ | but that's just me | 16:08 |
Ileden | yeah, it's not really a tool for this situation, I know. :-/ | 16:08 |
Ileden | It'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 |
LarstiQ | Ileden: something like the network_manager plugin might help there | 16:11 |
Ileden | what are the issues using --local, by the way? | 16:12 |
LarstiQ | Ileden: `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 |
Ileden | LarstiQ: Ok. Well, thanks for all the information! I'll try to figure out which would be the best approach for me. | 16:15 |
LarstiQ | Ileden: you gave me an interesting idea for changing the network_manager plugin anyway :) | 16:16 |
Ileden | :D | 16:18 |
goodmami | bzr status says I have a pending merge, but bzr merge says "Nothing to do". any ideas? | 18:22 |
Necoro | goodmami: if you have a pending merge, you already merged ... so "bzr merge" won't do anything | 18:23 |
Necoro | you need to commit | 18:23 |
goodmami | Necoro, thanks. I was confused because my "bzr pull"s were failing and telling me to do a merge | 18:24 |
goodmami | i'll try a commit | 18:24 |
LarstiQ | goodmami: when pull complains the branches are diverged, you bzr merge; (bzr st; bzr diff, etc to make sure everything is ok); bzr commit | 18:26 |
goodmami | LarstiQ, 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 developer | 18:30 |
goodmami | (my other developer's changes were the ones i was having trouble merging into my tree) | 18:30 |
LarstiQ | goodmami: it sounds like his changes are now merged revisions, and not mainline | 18:32 |
LarstiQ | goodmami: does `bzr missing` from his branch to the one you just pushed to claim the revisions are actually missing? | 18:32 |
goodmami | LarstiQ, yeah perhaps. The repo is hosted by a launchpad team, of which both he and I are members | 18:32 |
LarstiQ | goodmami: also see bzr log --long (and -n0 if using a new enough bzr) | 18:32 |
LarstiQ | goodmami: the launchpad web interface doesn't show all revisions, just the mainline ones. | 18:33 |
LarstiQ | goodmami: lp:glot? | 18:34 |
goodmami | oh ok, i see his messages in the log file. they are under (indented in) my merge | 18:34 |
goodmami | LarstiQ, yes | 18:34 |
goodmami | launchpad did show his changes until i did the last push, so i figured his were mainline | 18:34 |
LarstiQ | goodmami: when you merged his changes and then committed, you reordered the mainline | 18:35 |
goodmami | LarstiQ, oh. hm. i guess that can happen, huh. | 18:35 |
LarstiQ | goodmami: it can happen. It is indeed not the recommended workflow. | 18:35 |
goodmami | LarstiQ, how do I avoid this in the future? should only one person do pushes to the mainline? | 18:36 |
LarstiQ | goodmami: the trick is to merge into the trunk, not merge the trunk into your branch and then push it over trunk | 18:37 |
LarstiQ | goodmami: say you have ~/src/glot/trunk and ~/src/glot/mami | 18:37 |
LarstiQ | goodmami: 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:glot | 18:38 |
LarstiQ | goodmami: you've now probably done, from ~/src/glot/mami; bzr pull (lp:glot) -> message about divergance; bzr merge; bzr ci; bzr push | 18:38 |
LarstiQ | goodmami: if instead of that you did, cd ~/src/glot/trunk; bzr pull; bzr merge ../mami; bzr ci; bzr push; cd ../mami; bzr pull | 18:39 |
LarstiQ | goodmami: then his changes would have the same revnos they had (still on the mainline) | 18:39 |
goodmami | LarstiQ, I see what you mean, but I was working in trunk (probably not the best idea) | 18:40 |
LarstiQ | goodmami: and then your changes would not be shown by the launchpad web interface | 18:40 |
goodmami | LarstiQ, I had some changes that i committed, and when i pushed it said I didn't have an up to date tree or something | 18:40 |
LarstiQ | goodmami: right | 18:40 |
goodmami | LarstiQ, so I think I did a pull and a merge | 18:41 |
* LarstiQ nods | 18:41 | |
LarstiQ | goodmami: there isn't anything technically wrong with how you did things, his changes are still present. | 18:41 |
LarstiQ | goodmami: it is just presenting a different view on history. | 18:41 |
goodmami | LarstiQ, 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 his | 18:42 |
LarstiQ | which I admit us humans aren't always comfortable with | 18:42 |
LarstiQ | goodmami: it had a conflict? | 18:42 |
goodmami | LarstiQ, great, now I'm a historical revisionist... ;) | 18:42 |
LarstiQ | goodmami: only the victors get to rewrite history ;) | 18:42 |
goodmami | LarstiQ, it didn't have a conflict, but it complained about it, so I assumed there was a conflict | 18:42 |
goodmami | LarstiQ, so... I win? | 18:42 |
goodmami | LarstiQ, anyway, I'll be more careful about that now. thanks for the help | 18:43 |
LarstiQ | goodmami: in the sense of determing which revisions are the mainline, yes, you just won. | 18:43 |
LarstiQ | bzr has an option to disable reordering the mainline, I'm not sure if launchpad can support that too | 18:43 |
goodmami | ah | 18:44 |
goodmami | LarstiQ, well hopefully we won't come across this again. | 18:44 |
LarstiQ | append_revisions_only | 18:44 |
goodmami | thanks | 18:44 |
LarstiQ | (dredged up from `bzr help configuration`) | 18:44 |
goodmami | ooh, i'll go check that out | 18:45 |
LarstiQ | goodmami: please do :) | 18:45 |
LarstiQ | feedback welcome | 18:45 |
goodmami | sure | 18:45 |
goodmami | thanks again | 18:45 |
stbuehler | what 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 |
LarstiQ | no other changes to the svn repo? | 20:22 |
LarstiQ | no editing of the tags on the bzr side? | 20:22 |
stbuehler | i don't know for sure, but i don't thinks o | 20:31 |
LarstiQ | stbuehler: then my ideas are depleted and you'll have to ask jelmer | 20:33 |
stbuehler | any simpler way restoring this than rebranching it? i do not really care about my bzr history, i use bzr just as a frontend to svn | 20:33 |
LarstiQ | stbuehler: does the push actually fail, or is it just a message? I suspect the latter. | 20:34 |
stbuehler | just a message | 20:35 |
stbuehler | but i don't like it :) | 20:35 |
LarstiQ | stbuehler: does it repeat on later pushes? | 20:37 |
LarstiQ | stbuehler: and yes, it should go away after rebranching | 20:37 |
stbuehler | yes | 20:37 |
LarstiQ | stbuehler: 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 hand | 20:38 |
stbuehler | i deleted some tags and pushed again -> no warning for them. bzr pull, tags reappeared, and with the next push the warning came back | 20:47 |
LarstiQ | stbuehler: ok. Have you looked through open bzr(-svn) bugs on tags? | 20:51 |
gotgenes | I'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 |
LarstiQ | gotgenes: what version of python and bzr are you using? | 21:03 |
gotgenes | looks like python 2.5.1 installed to /usr/local | 21:03 |
gotgenes | bzr 1.13.1 from source | 21:04 |
LarstiQ | gotgenes: can you pastebin the backtrace? | 21:04 |
gotgenes | LarstiQ: Sure | 21:04 |
gotgenes | one sec | 21:04 |
LarstiQ | gotgenes: note that you can run bzr from source, no installation needed | 21:04 |
LarstiQ | (running make is still a good idea for more performance) | 21:05 |
gotgenes | LarstiQ: http://rafb.net/p/yXkGrD79.html | 21:06 |
LarstiQ | gotgenes: that looks like your python install is broken. | 21:07 |
LarstiQ | gotgenes: or at the very least doesn't contain the modules one expects from stdlib. | 21:08 |
LarstiQ | gotgenes: is this a python2.5-minimal package or somesuch? | 21:08 |
gotgenes | LarstiQ: Possibly. I'm not the sysadmin for that box, unfortunately. | 21:08 |
gotgenes | LarstiQ: Quite likely. | 21:08 |
gotgenes | Supposedly it was downloaded from source. | 21:08 |
LarstiQ | gotgenes: python -c 'from hashlib import md5' breaks, right? Does python -c 'import md5' fail as well? | 21:11 |
gotgenes | LarstiQ: Yes, I just ran that. | 21:11 |
LarstiQ | gotgenes: if so, I'd bug the admin asking for a working python install. | 21:11 |
gotgenes | LarstiQ: It seems I'll need to. | 21:12 |
LarstiQ | gotgenes: bzr does really need that to operate, is installing your own copy of python an option in the mean time? | 21:12 |
gotgenes | LarstiQ: Sure, into my home directory | 21:12 |
gotgenes | Suppose that's not too hard to do | 21:12 |
gotgenes | LarstiQ: installed Python to the home dir and bazaar installed fine after | 21:43 |
LarstiQ | gotgenes: cool | 21:45 |
gotgenes | Thanks for your help. | 21:47 |
jml | hello | 23:54 |
jml | I was looking at bug 351686, and wondering whether it's even possible with Bazaar | 23:55 |
ubottu | Launchpad bug 351686 in launchpad-bazaar "Merge proposal diffs should use -p option" [Undecided,New] https://launchpad.net/bugs/351686 | 23:55 |
lifeless | small matter of code | 23:58 |
lifeless | -p is actually a regex search up from the change region | 23:58 |
lifeless | we support external diff options too if you're invoking diff | 23:59 |
jml | cool. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!