| lifeless | sssss | 01:34 |
|---|---|---|
| litwol | Hello. Is there a way in bzr to find out what will be updated if i execue 'bzr update' command ? similar to 'svn status -u' | 01:52 |
| spiv | litwol: hmm, not that I know of. It probably ought to have a --dry-run or --preview option (like 'bzr commit' and 'bzr merge' do, respectively). | 02:34 |
| spiv | litwol: file a bug? | 02:34 |
| lifeless | hi poolie | 02:49 |
| twisted_steel | what is the option to package all files from a repository into a tar.gz? I did it 6 months ago, but can't find it any more | 03:14 |
| lifeless | bzr export foo.tar.gz | 03:14 |
| twisted_steel | ahh, export. thank you | 03:14 |
| === khmarbaise_ is now known as khmarbaise | ||
| pattern | i interrupted bzr in the middle of a commit... is there a chance of its database getting corrupted? | 05:23 |
| Peng | pattern: Perhaps if you're using an extremely old disk format. But otherwise no. | 05:31 |
| pattern | cool | 05:33 |
| pattern | thanks | 05:33 |
| vila | spiv: ping | 07:36 |
| vila | hi all ! :) | 07:36 |
| === gerard_1 is now known as gerard_ | ||
| Anteru | Hi | 08:47 |
| gerard_ | sooooooo | 09:25 |
| gerard_ | when is this bug going to be fixed? https://bugs.launchpad.net/bzr/+bug/113809 | 09:25 |
| ubottu | Ubuntu bug 113809 in bzr "update performs two merges" [High,Confirmed] | 09:25 |
| gerard_ | the attached patch looks good to me (though I have only little experience with the internal workings of bzr) | 09:25 |
| gerard_ | gogo bazaar devs | 09:26 |
| gerard_ | I love the rest of bazaar but this just plain sucks | 09:26 |
| gerard_ | that bug is a duplicate of a lot of other bugs btw | 09:28 |
| gerard_ | those really should be marked that way | 09:28 |
| spiv | gerard_: huh, there's a patch that was partially approved that disappeared. | 09:29 |
| spiv | gerard_: I just poked vila, the patch pilot this week, by email to suggest he take a look. | 09:33 |
| gerard_ | thx | 09:33 |
| gerard_ | my boss already finds bazaar a little scary, no need to keep bugs like this around | 09:34 |
| vila | spiv, gerard_ : I'll have a look at it but it seems to require more work, it was reviewed 'Needs_fixing' not 'Approved' | 09:36 |
| vila | spiv: are you around or not really ? | 09:36 |
| === gerard_1 is now known as gerard_ | ||
| gerard_ | vila: is there any reason noted why it needs fixing? | 09:54 |
| vila | https://code.edge.launchpad.net/~craighewetson/bzr/update_with_local_commit/+merge/10320 | 09:55 |
| spiv | vila: not really, but I may glance at IRC from time to time... | 09:55 |
| vila | spiv: ok, how about a few questions of the per-file merge hook ? There are two points that compromise the landing: 1) repeated access to the config, 2) license for the cachedproperty | 09:56 |
| vila | spiv: you're away until thursfay (at least) right ? | 09:57 |
| vila | surfday, yes, *Thursday* damn it | 09:57 |
| gerard_ | vila: ah, so it needs some minor changes? | 10:01 |
| gerard_ | I could make those later this week | 10:01 |
| gerard_ | I've already written a testcase for it anyway | 10:01 |
| gerard_ | I think I also have a better error message | 10:02 |
| vila | gerard_: good, I'll look into it then, the weird thing is that the merge proposal is marked as 'Merged'... | 10:03 |
| spiv | vila: for 1, make the plugin store it on the hook params, e.g. "val = getattr(params, 'news_merge_files, None); if val is None: ..." | 10:03 |
| spiv | vila: for 2, someone needs to ask an LP person about it | 10:03 |
| spiv | vila: it's not "crown jewels" code so I doubt there will be any issue, but it might take time to find the right person and get them to say "ok". | 10:04 |
| vila | spiv: 1) ! of course, I thought about caching it but didn't think about letting the plugin do it | 10:04 |
| vila | 2) But why do you think your first version was bogus ? I didn't *test* it properly but.. | 10:04 |
| spiv | vila: probably flacoste or maybe even ask jml | 10:05 |
| spiv | vila: the cache was global, not per instance | 10:05 |
| vila | global ? A local variable ? What makes you think so ? | 10:05 |
| spiv | (Two different definitions that used @cachedproperty would have their own cache, but not two instances of a class) | 10:06 |
| vila | ha, yes | 10:06 |
| vila | hmm, still, I preferred your lighter version :-/ | 10:06 |
| spiv | vila: try "class C(object): def __init__(self, x): self.x = x; @cachedproperty; def y(self): return x**2", then "print C(1).y, C(2).y" | 10:06 |
| spiv | vila: so, FWIW, I read through the LP version and I think it's good and correct | 10:07 |
| spiv | vila: and as short as it can reasonably be while being as featureful and clear as it is. | 10:07 |
| vila | spiv: ok, I'll look into it and try to get an approval for the additional diff (time to use that pre-requisite parameter again :) | 10:08 |
| vila | gerard_: weirder, it seems that the original branch has been replaced with bzr.dev, lp shows an *empty* diff so I don't even know where the code is right now, I'll ping craig in the mp about it | 10:16 |
| gerard_ | vila: :o | 10:18 |
| vila | gerard_: That's the first time I see such a weird thing... | 10:19 |
| cjwatson | so, the new 'bzr rebase-foreign' command sounds like exactly what I've been after for a while. However, when I run it (in a checkout of lp:~ubuntu-cdimage/debian-cd/ubuntu, with NEW_BASE pointing to a checkout of lp:debian-cd) it just says "Nothing to do." Am I doing something wrong? | 11:48 |
| cjwatson | is it possible that bzr-rewrite can only deal with branches imported using things like bzr-svn, not cscvs? | 11:48 |
| cjwatson | I wouldn't mind (all that much) having to generate a map for it matching up old and new revision ids, if I knew how ... | 11:49 |
| swathanthran | can i some how know how much data i would be downloading, before doing a bzr update? | 12:36 |
| * swathanthran wanted to update his emacs trunk. | 12:36 | |
| === mrevell is now known as mrevell-lunch | ||
| maxb | swathanthran: I don't think such support exists. | 12:56 |
| vila | cjwatson: I don't think there are constraints on the branches except for some common ancestry and the fact that the revisions you want to rebase are not already part of the branch you're targetting, but I confess no experience with rebase-foreign | 13:08 |
| maxb | cjwatson: I think the problem is that your branches don't match one of the preexisting matcher algorithms written into the plugin. Some custom hackery is probably needed. Especially as there seems to be an off-by-one relationship in revision numbers and arch patch-X numbers between the two branches. | 13:12 |
| cjwatson | maxb: indeed, base-0 would translate to r1 in bzr-speak, patch-1 to r2, etc. | 13:20 |
| maxb | Not quite what I meant - both of your branches have arch-derived revids, but base-0 in one is patch-1 in the other | 13:20 |
| Morbus | g'day, i'm trying to tweak the bzr emailer.py to get the branch nick into the subject line. | 13:32 |
| Morbus | so, since branch is added to self in the init, i was hoping to add self.branch to the subject() function. | 13:32 |
| Morbus | but, i'm not sure how to get the branch *nick* - i'm not a python coder. | 13:32 |
| Morbus | is it just magically branch.nick? ;) | 13:33 |
| Morbus | self.branch.nick, rather. | 13:33 |
| maxb | try it and see? (I think it is) | 13:33 |
| Morbus | yeah, i had just tried it, but intro'd a syntax error somewhere else and panicked ;) | 13:34 |
| * Morbus is trying again. | 13:34 | |
| vila | it is, but where did you find an emailer.py ? | 13:34 |
| Morbus | bzr: ERROR: Server sent an unexpected error: ('error', 'not all arguments converted during string formatting') | 13:34 |
| Morbus | https://launchpad.net/bzr-email/trunk | 13:34 |
| Morbus | also linked from the bzr plugin handbook guide thingy. | 13:35 |
| vila | yeah the plugin, found it fater asking ;) | 13:35 |
| vila | err, after | 13:35 |
| Morbus | def subject(self): | 13:35 |
| Morbus | return ("[bzr] [%s] r%d - %s" % | 13:35 |
| Morbus | (self.branch.nick, | 13:35 |
| Morbus | self.revno, | 13:35 |
| Morbus | is the start of my revised subject line. | 13:35 |
| Morbus | and is giving the above error. | 13:35 |
| Morbus | on commit. | 13:35 |
| vila | the error means that you have more arguments than mentioned in the format, | 13:36 |
| Morbus | ah, tht's true. | 13:36 |
| vila | Use paste.ubuntu.com instead of pasting here | 13:36 |
| Morbus | i left the url in cos i didn't want to delete it. | 13:36 |
| Morbus | thought extra args would just be ignored. | 13:36 |
| vila | Morbus: ha, coming from C ? ;-) | 13:37 |
| Morbus | nah, php/perl. | 13:37 |
| Morbus | i don't even know if it works over there, honestly ;) | 13:37 |
| Morbus | welp, no errors that time. | 13:38 |
| Morbus | now just have to wait for the email. | 13:38 |
| Morbus | :D | 13:38 |
| vila | Morbus: congratulations ! | 13:38 |
| Morbus | i'm surprised emailer isn't being regularly updated. | 13:38 |
| vila | Morbus: bzr core is, I'm pretty sure almost all of emailer.py should be deprecated and use the core version instead but nobody found the time to do that so far | 13:39 |
| Morbus | vila: wait, there's a core version? | 13:39 |
| Morbus | since when? | 13:39 |
| Morbus | i just set this up a few months ago. | 13:39 |
| vila | Morbus: well, smtp_connection is part of core, I'm sure about that. There are certainly features of bzr-email that are not, I just don't know exactly which | 13:40 |
| maxb | cjwatson: I hacked it to guess the relationship between your revids, and it rebased 395 revisions, but then it exploded with an AssertionError when it first hit a merge in the ubuntu branch. I'm afraid I'm out of time to look at it today. :-/ | 13:40 |
| Morbus | vila: ah. | 13:41 |
| Morbus | email came through. self.branch.nick works fine. thanks much. | 13:47 |
| cjwatson | maxb: *nod*, thanks for looking | 13:48 |
| === mrevell-lunch is now known as mrevell | ||
| swathanthran | ok.. i used http://bzr.savannah.gnu.org/r/emacs/trunk/ to do the initial checkout last week.. now it looks like that trunk is blank but latest revision is seen on lp how can i change the url of bzr update? | 13:53 |
| cjwatson | swathanthran: you mean blank as seen in a web browser? | 13:59 |
| vila | swathanthran: what does 'bzr log -l5 http://bzr.savannah.gnu.org/r/emacs/trunk' says ? | 14:02 |
| swathanthran | when i do bzr update it says uptodate upto revision 99318. but launchpad has it up to 99375 | 14:05 |
| swathanthran | bzr log -l5 shows only upto 2010-01-13 | 14:05 |
| vila | swathanthran: so the trunk is not blank, good. | 14:05 |
| vila | Now you have to decide which branch you want to track. Is the lp one supposed to be a mirror of the savannah one ? | 14:06 |
| swathanthran | oh sorry i forgot to add the link:) | 14:06 |
| rubbs | swathanthran: do you have a branch or checkout? | 14:07 |
| swathanthran | ok.. i have a checkout of trunk and i want to update trunk.. | 14:07 |
| swathanthran | bzr log -l5 http://bzr.savannah.gnu.org/r/emacs/trunk shows it upto 19 itself.. so the branch don't have a problem.. | 14:07 |
| swathanthran | terribly sorry i have to go out now.. | 14:08 |
| rubbs | oh. ok. I'll keep thinking | 14:08 |
| lornajane | apparently my branches have diverged. That doesn't sound good to me | 14:09 |
| vila | lornajane: 'bzr missing' should display the differences | 14:10 |
| rubbs | diverged branches mean that you have a branch and someone else has a branch and that you both want to push to the tree. The other person(s) have already pushed | 14:10 |
| rubbs | you have to do a merge to make yours work | 14:10 |
| lornajane | yes, I've been offline for a few days | 14:10 |
| lornajane | I have a lot of local commits and the rest of the team have been working too | 14:11 |
| lornajane | this is exactly why I use bzr-svn :) | 14:11 |
| lornajane | its just that I've only just started and I'm confused. Your explanation doesn't sound like its broken though, so I'll try the missing thing and see what happens | 14:11 |
| lornajane | The bzr error message about the diverged branches was very friendly and helpful | 14:11 |
| rubbs | good to hear. | 14:12 |
| rubbs | lornajane: http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/tutorial.html?#merging-from-related-branches that might help a little too | 14:14 |
| lornajane | rubbs: thanks! I'll look | 14:14 |
| rubbs | np | 14:14 |
| lornajane | I expected it to just update and either merge it or conflict | 14:15 |
| rubbs | bzr tries to do the safest thing when possible. It wants you to merge it explicitly because a merge in the background could throw some things off. | 14:17 |
| rubbs | it's safer to just tell you that the branches are now diverged and let you know that you have to merge them. | 14:17 |
| toytoy | guys, anyone have successfully installed bazaar in eclipse? | 14:18 |
| toytoy | rubbs, are you talking to me? | 14:19 |
| lornajane | rubbs: makes sense once you know that's what's happening | 14:19 |
| toytoy | ah no, sorry | 14:19 |
| rubbs | toytoy: heh. no problem. | 14:20 |
| rubbs | lornajane: good. We try to make it less complicated | 14:20 |
| rubbs | toytoy: I haven't played with eclipse in a long while. | 14:20 |
| rubbs | toytoy: are you looking for full integration? | 14:20 |
| rubbs | or just looking for bzr to be separate? | 14:21 |
| === vednis is now known as mars | ||
| toytoy | rubbs: yeah, somewhat like cvs feature in eclipse. that is cool! I want something like that for bazaar. is there any? | 14:30 |
| rubbs | as far as I know, there is, but it takes some setting up. I'll see if I can find the docs again. | 14:31 |
| lornajane | I don't think I understand the workflow of this :( So normally I just pull changes | 14:32 |
| lornajane | my branches had diverged, which is fine | 14:33 |
| lornajane | so I merged, I got a conflict, I resolved that and marked it as resolved | 14:33 |
| lornajane | now I'm confused by two things | 14:33 |
| lornajane | one: stuff that is coming in is showing as local changes in my working directory | 14:33 |
| lornajane | two: I have a pending merge tip, no idea what that is or what I should do about it | 14:34 |
| lornajane | should I be RTFMing? I can't quite see how this process is going to work | 14:34 |
| rubbs | toytoy: http://wiki.bazaar.canonical.com/BzrEclipse/Installation | 14:35 |
| toytoy | okay rubbs, I found one but yeah it doesn't work perhaps i need to do more. I got this error bzr: Error: no such option: --short | 14:35 |
| toytoy | do you know that one? yeah that's the one i'm installing, indeed | 14:35 |
| rubbs | toytoy: I'm not sure if bzreclipse is still in active development. I'm not sure if anyone else knows more. I know it has been done before, I just can't find out where. | 14:36 |
| rubbs | lornajane: problem one: My guess is you have one branch, and you merged in your changes from the trunk correct? | 14:37 |
| lornajane | rubbs: correct | 14:38 |
| rubbs | lornajane: if that is the case, then that is the reason your trunk looks like the "local" branch. When doing a merge, the place you are merging is on the left side. The place you are getting the merge from (i.e. the trunk) is always on the right. There is a way to get around this... | 14:39 |
| rubbs | lornajane: you actually need two branches in this case (if you always want to make the trunk on the left). One branch will be your branch you have now. and the other branch will be a Mirror of the trunk. | 14:40 |
| rubbs | so you would have to create a branch from the trunk. cd into that mirrored branch, and then merge in the changes from your original branch. | 14:40 |
| rubbs | then you can push your mirrored branch back to the trunk. | 14:41 |
| rubbs | does this make sense so far? | 14:41 |
| rubbs | it's a little complicated, but once you get it, it kind of make sense | 14:42 |
| rubbs | you want a "mirror" of your trunk, and a "working branch." Once you are done with your working branch, you merge them into your "mirror" and then push from the mirror. Your working branch can then be updated. | 14:43 |
| lornajane | I *think* I understand :) | 14:44 |
| rubbs | for problem two it's a little more simple | 14:44 |
| rubbs | bzr doesn't automatically commit after all the conflicts are marked resolve (or for any merge for that matter). To finish your merge you have to do a commit. I usually just say "merging in xxx branch" in the message. | 14:45 |
| lornajane | right | 14:46 |
| rubbs | the pending merge tip is just telling you that in this commit the merge will take the two "tips" or "heads" and merge them to one. | 14:48 |
| rubbs | I might raise a bug about how best to set up a workflow for people in your situation. We've had a few people with similar problems before. | 14:49 |
| === salgado is now known as salgado-lunch | ||
| lornajane | rubbs: even a picture I think would help. I am confident with SVN and I can't be the only person moving over | 14:53 |
| rubbs | I think I'm gonna work on that now. I'm working on a "google doc" that will be really basic, but at least it's something. | 14:54 |
| rubbs | I'll show it to you in a few minutes. | 14:54 |
| rubbs | after I show you I'll work on polishing it up. | 14:54 |
| lornajane | rubbs: sounds great :) I hope I'm not making work for you! | 14:55 |
| rubbs | lornajane: not at all! your distracting me from work I really don't want to do (I've been searching for a reason to procrastinate all morning ;) ) and I have plenty of time to get it done | 14:56 |
| === jfroy_ is now known as jfroy | ||
| lornajane | so, I'm definitely making progress, but I'm sort of confused on what to do next | 15:01 |
| lornajane | I have updated and put my branch changes into my trunk. Now I want to push the commits I made back to subversion (I used bzr-svn to check out). Can I send the commits as they were done locally or can it only be a monster commit? | 15:03 |
| rubbs | lornajane: you know, I'm not entirely sure (I've done very little bzr-svn work myself) | 15:06 |
| lornajane | rubbs: hehe, maybe I'll improvise and then blog about it. I can clean up in SVN if I have to | 15:07 |
| rubbs | I'm sorry. | 15:07 |
| vish | hi.. how to do a merge in lp? ken Accepted the merge , but he isnt sure how to do it... ;) https://code.launchpad.net/~vish.../ubuntu/lucid/human-theme/bug507632+bug495644/+merge/17538 | 15:07 |
| vish | do i set the status to "merged" or... does he have to do it? | 15:07 |
| rubbs | vish: whoever has write access to that particular branch can do it. They do it by pulling from the trunk (mirror whats on lp) and then merge in the changes from your trunk (off of lp) and then push the result to the lp trunk. At least I'm pretty sure that's what will work. It's been a while for me to be honest. | 15:09 |
| vish | ah , i thought so too.. :( | 15:10 |
| vish | but it seems a waste of bandwidth ;p if the user has changed only one line of a huge branch , the author has to fully download the merge branch too :s | 15:11 |
| rubbs | no... they don't actaully | 15:11 |
| rubbs | if they just use the lp: shortcuts, it only will download the changes | 15:11 |
| rubbs | so you only need a mirror of the trunk. | 15:11 |
| rubbs | using ssh+bzr will keep the bandwidth down to a minimum | 15:12 |
| rubbs | so in the trunk the command would be "bzr merge lp:branch-to-merge-from" and then once that's all done "bzr push lp:trunk" | 15:12 |
| rubbs | er by in the trunk I meant in the mirror of the trunk | 15:12 |
| vish | rubbs: ah.. ok thanks :) | 15:13 |
| rubbs | np | 15:13 |
| * cjwatson typos 'bzr blog'. Hmm. | 15:17 | |
| Kinnison | hmmmmm indeed | 15:19 |
| * Kinnison ruffles cjwatson | 15:19 | |
| cjwatson | LTNS! | 15:19 |
| cjwatson | jam: thanks so much for the fix for bug 494269. I find the notion of being able to change the tree root rather magical ... | 15:20 |
| ubottu | Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269 | 15:20 |
| maxb | ooh | 15:21 |
| jam | cjwatson: yeah, I think there are still some paths that don't get it right, but at least more of them are working now | 15:21 |
| vila | cjwatson: try lp:bzr-guess :-D | 15:21 |
| * maxb should retest | 15:21 | |
| vila | morning jam ! | 15:21 |
| jam | morning vila | 15:21 |
| maxb | I managed to get some WTs into an entertaining state by pull --overwrite-ing and unrelated branch | 15:22 |
| cjwatson | vila: hah | 15:22 |
| Kinnison | vila: ooh handy | 15:22 |
| * Kinnison installs | 15:22 | |
| vila | jam: just a quick check from patch pilot to patch pilot :) Do you still take care of the ignore-exception mp and the 392428 one ? | 15:22 |
| vila | bialix: any news about gary ? I don't remember seeing him here these days... | 15:23 |
| bialix | hi vila, jam, et al | 15:24 |
| bialix | vila: I've chatted with him last night | 15:24 |
| cjwatson | jam: merge-package (lp:ubuntu/vim <- lp:debian/vim) is mostly working now, but I'm getting a load of "Conflict adding files to Contents. Moved to root." What do those mean? | 15:24 |
| bialix | Gary made qbzr 0.14.6 release last night | 15:24 |
| cjwatson | Contents being an actual file in the vim tree | 15:24 |
| vila | bialix: ok, I'll ping him from lp about his unicode-bom-detect mp then | 15:24 |
| bialix | unicode? do you have a link? | 15:25 |
| vila | https://code.edge.launchpad.net/~garyvdm/bzr/unicode_bom_detect/+merge/17076 | 15:26 |
| bialix | thx | 15:27 |
| bialix | interesting | 15:28 |
| vila | bialix: Yeah, what did you expect from Gary ? :-D | 15:29 |
| bialix | me? anything! | 15:29 |
| vila | hehe | 15:31 |
| lornajane | I'm reading some instructions here http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/ which suggest I want to merge to the repository rather than pushing. Does anyone have any thoughts on that? I'm using bzr-svn and I want to push changes on my trunk back to subversion | 15:38 |
| rubbs | lornajane: not sure about what you just posted, I'd have to read it. but I finished my very rough slide presentation. | 15:41 |
| rubbs | here it is: http://docs.google.com/present/view?id=dhc4j5xm_90gr8227ch | 15:41 |
| rubbs | if the current directory marker is in open space that means the directory just above the branch directories. | 15:42 |
| rubbs | opps just realized that my permissions on that file were a little too tight. if you had trouble you should be able to view it now | 15:44 |
| lornajane | I can see it | 15:45 |
| lornajane | that's a good description of what I was doing with the simple changes | 15:45 |
| rubbs | ok, cool. I'm also reading the article you posted above. | 15:46 |
| rubbs | lornajane: the article correct, you want to merge into the mainline, but they mean the mirror of the mainline (I think). That means that your mirror on your computer should *always* be treated as if it were the subersion server. That way you always get your history right. Once you have checked that it's correct, you can then push up to the server. | 15:51 |
| lornajane | rubbs: but will my many commits to there be many commits to SVN or just one? | 15:51 |
| rubbs | just one. if you want to do many commits you need to look at rebasing. | 15:52 |
| lornajane | meh, I thought this was going to be much easier :) | 15:52 |
| rubbs | that article seems to have a section on it | 15:52 |
| rubbs | rebasing "rewrites history" so that all your commits look like they came from the latest revision instead of an old one (which is what is happeing with yours) | 15:53 |
| rubbs | that way you can then push up to the main branch and it will all look like your commits came from the tip. and you will get all your commits as little ones rather than as one big one | 15:53 |
| lornajane | that sounds promising | 15:53 |
| rubbs | it's a flaw with svn in that it doesn't keep merged history | 15:53 |
| lornajane | I'm hoping this will get easier/quicker as I get used to it | 15:54 |
| rubbs | that's why a merge in svn will look like one big commit. | 15:54 |
| lornajane | I've spent half my afternoon wondering how to update and commit :) | 15:54 |
| rubbs | lornajane: I don't use svn that much anymore but this will get easier with a little practice. most of it isn't that time consuming, just a little bit of work in the begining | 15:54 |
| rubbs | once you get a workflow that works, it's pretty easy | 15:54 |
| rubbs | < lornajane> I've spent half my afternoon wondering how to update and commit :) | 15:55 |
| rubbs | ^^ been there before | 15:55 |
| jam | cjwatson: my best guess is that the same file exists in both branches but with a different file-id, so we get a conflict and have to put the files side-by-side | 15:57 |
| lornajane | rubbs: yes I'm sure I've been here before too :) I'll always be using central SVN repos but I love having bzr functionality on my working copy, if I can figure this out its going to be excellent | 15:58 |
| rubbs | lornajane: I think it will work out for you. If you have more questions, just let us know. We'll try to help you out. | 16:02 |
| lornajane | rubbs: this channel has been great so far - and the community is the main reason I'm persevering with this rather than following the crowd in my sector to git | 16:05 |
| cjwatson | jam: that was my first guess, but there are no .moved files or similar in the working tree | 16:06 |
| jam | cjwatson: the other possibility is the root id issue. In that in one tree it looks like Contents should be in '' with root id X, and in the other tree it looks like it should be in '' with root id Y. And root id Y isn't present in the first tree, so it seems like a conflict | 16:06 |
| jam | (root ids are mostly allowed so that you can do stuff like join by reference or join by value, and have things show up in the appropriate subdir) | 16:07 |
| rubbs | lornajane: I use git a little too (for work) it's not bad. Their community has worked well for me. For me though... bzr-svn had a few less problems than git-svn and a whole lot less problems than hg-svn. That and bzr makes it easy to contribute back to them ;) | 16:07 |
| jam | it wasn't really intended that the *same* project should get 2 root ids | 16:07 |
| jam | however, people did 'bzr init' 2x, rather than 'bzr init + bzr branch' | 16:07 |
| jam | etc | 16:07 |
| jam | especially with the udd stuff | 16:07 |
| === salgado-lunch is now known as salgado | ||
| cjwatson | jam: right. It's a bit of an incomprehensible message though - what am I meant to do with a conflict when I have no alternatives to choose between? :-) | 16:08 |
| lornajane | rubbs: I just can't bear ruby fanboys telling me that if I don't think git is the best thing ever, then I know nothing. These are just tools and I just want to use them, not argue about it | 16:09 |
| lornajane | git is pretty good, sure, but if I'm going to get flamed in their channels then I'd rather use something else :) | 16:09 |
| rubbs | haha good points | 16:11 |
| === quicksil1er is now known as quicksilver | ||
| === beuno is now known as beuno-lunch | ||
| starenka_ | hi, i just want to checkout/branch source from a lp project (bzr :D), is there a way how to checkout "lightweight"? I mean i dont need any history, just need the lastest source to compile it | 17:19 |
| starenka_ | (bzr n00b, sorry) | 17:20 |
| jderose | starenka_: bzr checkout --lightweight YOUR_BRANCH | 17:21 |
| starenka_ | ty | 17:22 |
| === maxb_ is now known as maxb | ||
| === beuno-lunch is now known as beuno | ||
| === lifeless1 is now known as lifeless | ||
| eydaimon | I'm wanting to merge to specific files from one branch to another. bzr merge ../trunk/file1 ../trunk/file2 gives errors complaining about extra arguments, and merging one file at a time gives error during merging of second file saying there are uncommitted changes. How can I merge more than one file at a time? | 18:37 |
| Kinnison | Erm, bzr operates by revision for merging IIRC | 18:38 |
| Kinnison | so you can't really merge by file | 18:38 |
| Kinnison | (unless this is a new feature I didn't know about) | 18:38 |
| eydaimon | but it appears to be very possible to merge just one file | 18:38 |
| eydaimon | seems to me I would have to merge and commit one file at a time otherwise | 18:39 |
| eydaimon | and if I can do that, it should support multiple | 18:39 |
| Kinnison | Why do you want to only merge specific files; rather than revisions? | 18:39 |
| eydaimon | what if the files are spread out over multiple revisions? | 18:39 |
| eydaimon | and there are other changes in those revisions I don't want merged | 18:40 |
| Kinnison | Sounds like a very unfortunate situation | 18:42 |
| Kinnison | I honestly don't know; sorry | 18:43 |
| Kinnison | you could try: | 18:43 |
| Kinnison | for F in file1 file2 file3; do bzr merge -force ../trunk/$F; done | 18:43 |
| Kinnison | since the --force option makes merge ignore uncommmitted changes and continue anyway | 18:43 |
| eydaimon | well, luckily it's not happening. I can actually use the change | 18:43 |
| Kinnison | I'd prefer using the revisions | 18:44 |
| Kinnison | since then history is nice and neat | 18:44 |
| eydaimon | but to me it's easier to keep track of what files I need rather than the revision | 18:44 |
| eydaimon | and since the above case is possible... just seems like something that would be supported | 18:44 |
| eydaimon | what's the bzr file needed to specify username? | 18:46 |
| Kinnison | username? | 18:46 |
| maxb | eydaimon: Try using bzr help whoami | 18:47 |
| Kinnison | If you want to tell bzr what author/committer name to use, then do: bzr whoami "My Name <email@domain.com>" | 18:47 |
| eydaimon | found | 18:47 |
| eydaimon | ~/.bazaar/bazaar.conf | 18:47 |
| eydaimon | well, one guy is checking in as root... | 18:47 |
| Kinnison | that guy needs to be spanked | 18:47 |
| Kinnison | (unless you're doing some kind of etckeeper thing) | 18:47 |
| eydaimon | he didn't want to touch his mac by installing stuff on it, so he is running virtualbox with redhat and doing his dev on there.... | 18:50 |
| eydaimon | don't ask ... | 18:50 |
| * Kinnison won't :) | 19:00 | |
| lifeless | Kinnison: he might like it | 19:00 |
| Kinnison | In that case, even if I were tempted to ask; I wouldn't want to know :-) | 19:02 |
| eydaimon | heh | 19:15 |
| === salgado is now known as salgado-afk | ||
| Chocobo | Hi all. How well does bzr handle large files? I know this is an issue with hg and git. | 20:46 |
| luks | not much better, I guess | 20:48 |
| luks | what specifically are you interested in? | 20:48 |
| Chocobo | Oh I have a project with a lot of large binary data files. | 20:50 |
| lifeless | Chocobo: how large is large | 21:01 |
| Chocobo | 100 MB or so. | 21:01 |
| Chocobo | I would like to keep it in revision control because it is part of the project. | 21:02 |
| lifeless | as long as you have 300MB ram it should be fine. | 21:03 |
| lifeless | [and you are using 2.x] | 21:03 |
| NfNitLoop | Hrmm. 'bzr log' on this svn branch doesn't show 'svn revno:' for something I pushed from my local branch. | 21:04 |
| NfNitLoop | Not sure what's causing that... doesn't seem to generate an error or anything. | 21:05 |
| NfNitLoop | Oh, come to think of it, it doesn't show svn revno for anything that was a result of a merge, it seems. | 21:06 |
| NfNitLoop | I guess so it can continue to show the bzr mergeinfo? | 21:06 |
| maxb | Hmm, the bzr-beta-ppa is not in very good shape :-/ | 21:16 |
| maxb | Is there any convenient trick to running bzr from a working tree, but with C extensions? | 22:16 |
| maxb | Or should I find somewhere in my homedir to install it to, and use PATH and PYTHONPATH? | 22:16 |
| fullermd_ | `gmake` | 22:16 |
| maxb | oh, neat, I didn't even look for a Makefile once I'd seen the setup.py | 22:17 |
| === abentley1 is now known as abentley | ||
| igc | morning | 22:27 |
| lamont | given a CVS repo with N branches, and possibly some violations of nature (hi lifeless), is that trivial to import into bzr yet? even at one directory tree per branch? | 22:46 |
| lifeless | lamont: cvs2svn can output fast-import streams | 22:49 |
| lifeless | lamont: if it can handle your repo, then yes. | 22:50 |
| lamont | ah, cool | 22:50 |
| lifeless | lamont: as we can import fast import streams | 22:50 |
| lamont | and FWIW, it's not _my_ repo (this time) | 22:50 |
| * lamont cries a little as 'rcs' and 'subversion' both wind up on his machine | 22:51 | |
| maxb | cvs2svn(bzr) does a decent job these days. Give me a prod if you find a problem, I've been hacking on it lately | 22:53 |
| lamont | will do | 22:54 |
| rockstar | jam, you're not at LCA are you? | 23:02 |
| mwhudson | rockstar: he is not | 23:03 |
| jam | rockstar: nope, I believe lifeless is | 23:03 |
| rockstar | jam, I wonder if I might schedule a call with you tomorrow as I land the last of the branch upgrade work. | 23:04 |
| rockstar | Er, the launchpad branch upgrade work. | 23:04 |
| jam | rockstar: sure, what time is good for you? | 23:06 |
| jam | I need to be going soon, though | 23:06 |
| rockstar | jam, how 'bout 10 AM your time tomorrow? | 23:06 |
| jam | rockstar: sounds good right now | 23:07 |
| rockstar | jam, okay. If something comes up, feel free to send me an email with a new time. | 23:08 |
| === khmarbaise_ is now known as khmarbaise | ||
| maxb | bzr-rewrite is eating my brain | 23:19 |
| cjwatson | lamont: I did actually manage to use cscvs to import multiple branches; since there was already a cvs->bzr import on Launchpad using cscvs, I figured I was best off sticking with the same tool | 23:28 |
| lamont | cjwatson: coolness. | 23:29 |
| cjwatson | lamont: https://code.launchpad.net/~cjwatson/launchpad-cscvs/openssh-branch-imports for the gross hacks involved | 23:29 |
| lamont | nice | 23:29 |
| lamont | this is an NDA'ed CVS repo that 'git cvsimport' has a history of sometimes not liking | 23:29 |
| cjwatson | lamont: and http://bzr.debian.org/loggerhead/pkg-ssh/openssh/trunk/annotate/head:/debian/README.source? documents how to drive it. | 23:29 |
| cjwatson | lamont: oh, if cscvs hasn't already been involved, you might keep your sanity better by not involving it | 23:30 |
| lamont | it doesn't help that someone (and not me this time) has felt sufficiently of-clue to do manual surgery on the ,v files from time to time | 23:30 |
| cjwatson | that never helps | 23:30 |
| lamont | cvsps | 23:30 |
| cjwatson | my normal preference is to use something that spits out fast-import streams (like cvs2svn/cvs2git/whateveryoucallit), since they're hackable | 23:31 |
| lamont | one question that I might get an answer to (assuming it finishes): does cvs2git create consistent commit hashes? or will two imports of the same tree not give the same git tree? (ditto for cvs2bzr...) | 23:31 |
| cjwatson | there's no "cvs2bzr" AFAIK, it's more like cvs2git | bzr fast-import | 23:32 |
| lamont | cvs2svn: /usr/bin/cvs2bzr | 23:32 |
| lamont | beg differ | 23:33 |
| cjwatson | huh, so there is | 23:33 |
| cjwatson | wasn't last I looked. :) | 23:33 |
| lamont | gotta love these works in progress. | 23:33 |
| lamont | 375MB cvs tree -> 2.5GB and counting blob file | 23:33 |
| === sdboyer_ is now known as sdboyer | ||
| lamont | meanwhile, git cvsimport: WARNING: Invalid PatchSet 7114, Tag v9_0_base: | 23:34 |
| cjwatson | anyway, cvs2bzr is just slightly tweaked output versus cvs2git, it still requires use of bzr fast-import | 23:36 |
| lamont | and given that upstream is cvs, and I have my git tree for debian/ubuntu, and the whole tree is totally NDA, I'm inclined to leave it in git for the moment, and then play with it in bzr and make sure cvs2bzr is doing the right thing. | 23:36 |
| cjwatson | and bzr fast-import doesn't guarantee consistent revision-ids | 23:36 |
| lamont | maxb: cvs2bzr would be far more useful to me if it could do a delta addon to an existing previous result from cvs2bzr | 23:36 |
| cjwatson | I don't know about cvs2git | git fast-import | 23:36 |
| maxb | lamont: So say many people, but converting from CVS doesn't lend itself to that | 23:37 |
| lamont | well, running 2 copies of cvs2git now, just to see what it does. | 23:37 |
| cjwatson | however, to amend my previous comment | 23:37 |
| cjwatson | bzr fast-import permits storage of "fastimport-id-map" in the .bzr/repository | 23:37 |
| maxb | cjwatson: Well I've worked out what the bug in bzr rebase-foreign is, but I don't know how to fix is :-/ | 23:37 |
| cjwatson | if you do that, then successive imports into the same repository will be idempotent | 23:37 |
| lamont | maxb: so I've told upstream. in the end, I got rsync access to the ,v files, and "CVS has worked for us so far, no reason to change" by way of an answer about joining the current VCS world | 23:37 |
| cjwatson | so it *is* possible to do delta imports, that way | 23:37 |
| cjwatson | in fact I do that myself with debian-policy | 23:38 |
| lamont | cjwatson: awesome | 23:38 |
| cjwatson | rebasing will break it | 23:38 |
| lamont | that's because rebase always breaks things | 23:39 |
| cjwatson | http://paste.ubuntu.com/359284/ is the script I use to update my debian-policy bzr import | 23:39 |
| cjwatson | should switch to bzr-git one of these days | 23:39 |
| maxb | I don't think fastimport storing a map file will work to allow delta imports from cvs2bzr | 23:39 |
| maxb | Perturbation in the cvs repository could cause cvs2bzr to resolve changesets differently | 23:39 |
| cjwatson | depends on level of branch complexity | 23:40 |
| cjwatson | if there's weirdness regarding default branches, then possibly | 23:40 |
| lamont | "This is a necessary workaround for the fact that CVS tags are fundamentally different than git tags.)" <-- no, it's because CVS tags are fundamentally b0rked | 23:40 |
| cjwatson | you could also manually chop off the dump file before a certain timestamp, and hack it to start from a given revision | 23:41 |
| cjwatson | fast-import lends itself to that kind of hackery if you're sufficiently desperate | 23:41 |
| cjwatson | though generally once I fast-import from CVS I throw away the original as fast as humanly possible, admittedly | 23:42 |
| lamont | but for me, for whatever reason, the commit IDs turn out different every time I import. <-- sigh | 23:42 |
| lamont | I think it might be time to reopen the discussion with upstream... | 23:43 |
| maxb | Hmm, I wish jelmer was around. | 23:46 |
| lamont | WARNING: in '....' branch '...' already has name 'foo', cannot also have name 'bar', ignoring the latter | 23:56 |
| lamont | I wonder if that means they assigned a branch 2 names | 23:57 |
| lamont | cjwatson: I | 23:57 |
| lamont | d pay cash money to get the original CVS thrown away in this case.... just not enough money to convince upstream, yet. | 23:58 |
| lamont | of course, there'd be more negotiability if the repo weren't so private | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!