| poolie | i'm looking at marius's nick-switching patch | 00:10 |
|---|---|---|
| === pasky is now known as gitsky | ||
| === mw is now known as mw|out | ||
| grettke | Do you guys have a preferred way of migrating svn repos to bzr? | 01:15 |
| poolie | grettke, either svn2bzr or bzr-svn (which can also round trip back to svn) | 01:25 |
| poolie | i'm not sure, svn2bzr may be better for a one-off conversion? | 01:25 |
| poolie | but i'd probably try bzr-svn first | 01:25 |
| grettke | poolie: I just tried bzr-svn and it blew up. | 01:28 |
| grettke | poolie: I am interested in a one-time conversion. | 01:28 |
| poolie | http://bazaar-vcs.org/svn2bzr | 01:28 |
| grettke | poolie: I've got so much cruft in my old svn repo, I wonder if it is worth filtering... | 01:29 |
| synic | got kind of a dumb question. I've got a project that we've been using bzr on for some time now. We started a new version of the project and instead of creating a branch, we created a new repo. I'd kind of like to merge the new repo with the old one so that we have a complete version history. Is this possible? | 03:14 |
| Verterok | synic: take a look to: 'bzr help join' | 03:22 |
| synic | k | 03:25 |
| synic | Verterok: hrmm, I'm a bit confused. It keeps saying that both trees have the same root id | 03:40 |
| Verterok | synic: mmm, maybe using merge? | 03:47 |
| poolie | ah, so the new branch should have come from the old one, but did not? | 03:48 |
| poolie | try bzr-rebase | 03:48 |
| poolie | (reading the btree prefetch) | 03:48 |
| synic | ok | 03:50 |
| synic | poolie: got an example of using rebase? | 03:57 |
| synic | bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 03:57 |
| synic | it's the same error I got when attempting to merge | 03:57 |
| poolie | actually, is there a reason not to just merge the trees? | 03:58 |
| synic | well, no, but I get an error when trying to do that. | 03:59 |
| lifeless | synic: so the error about same root | 04:03 |
| lifeless | synic: is because join is intended for rich roots | 04:03 |
| lifeless | synic: j-a-meinel wrote a plugin | 04:03 |
| lifeless | merge-into | 04:03 |
| lifeless | which is a less featureful join and should work for you | 04:04 |
| synic | it'll preserve the histories of both branches? | 04:04 |
| lifeless | synic: yes | 04:04 |
| === jamesh_ is now known as jamesh | ||
| vila | hi all | 06:59 |
| poolie | hello vila! | 07:11 |
| Rolly | just curious, has there been any progress on supporting nested trees? Last activity I can see was in the middle of 2007 | 08:13 |
| damohickey | Hello! | 10:31 |
| damohickey | First time using IRC. Is anyone else seeing this? | 10:34 |
| mwhudson | yes | 10:35 |
| damohickey | Hi, Is this an appropriate place to discuss conversion of an Open Source project from SVN to Bazaar or is it about Bazaar development only? | 10:38 |
| mwhudson | nope, conversions are definitely on topic | 10:39 |
| damohickey | Well this is a hard question to answer but we need to prepare for this eventuality. | 10:41 |
| damohickey | I am the leader of an Open Source eCommerce project called Freeway. We use SVN in a kind of interesting way that is not really productive for our conversion from company project to community distributed. | 10:42 |
| damohickey | We have a public SVN but that is fed by scripts from a private internal SVN. | 10:43 |
| damohickey | I'm just wondering what the impact would be when we move to Launchpad as it seems to logical thing to do now. | 10:43 |
| damohickey | By impact, I mean would we have to prepare for lotts of developers wanting to contribute all of a sudden; our project is pretty interesting but not well known now. | 10:44 |
| damohickey | We are happy enough for this to happen but want to get some idea of what happens when in the practical world when tightly controlled SVN projects open themselves to distributed version control. | 10:46 |
| damohickey | I understand there are multiple other factors involved. Perhaps my question is are there lots of people that wait for new projects using Bazaar in Launchpad, a pent up demand of people as annoyed with SVN as us? | 10:47 |
| damohickey | I'm sure this is a trivial concern. It's a different world thinking about distributed version control though. Very interesting, kind of like a new way of transacting with the world. | 10:50 |
| luks | people normally don't wait for random projects to open their development model | 10:50 |
| luks | even less so bzr users, which are a minority | 10:50 |
| === thekorn is now known as hoffenheim | ||
| luks | if people contributed to your project before they will most likely continue even if you switch to bzr, people who are not interested will not contribute no matter what VCS will you use | 10:52 |
| === hoffenheim is now known as thekorn | ||
| damohickey | A lot of our users (not developers) find it hard to use Torotoise SVN to get new stuff. Is there a particularly good promotional tool we can use to sell people on learning Bazaar? | 10:56 |
| luks | honestly, if they find tortoisesvn hard to use, they will probably find bzr impossible to use | 10:57 |
| damohickey | In some ways, this just means we have to manage our releases really carefully. | 11:03 |
| damohickey | I'm happy enough to move still. | 11:03 |
| damohickey | Bye for now. Thanks so much to all you people here who have contributed to the development of Bazaar. It is a really exciting process we are about to embark on. Thanks! | 11:05 |
| mwhudson | damohickey: have fun | 11:06 |
| dissonans | bzr-svn 0.4.13 is buggy for me on Python 2.6, Windows XP | 11:42 |
| dissonans | should I use some other version? | 11:42 |
| beuno | dissonans, I don't think that iether bzr or bzr-svn have been fully tested in 2.6 | 11:45 |
| mwhudson | bzr at least mostly works | 11:46 |
| dissonans | I have to use bzr 1.7 due to bzr-svn | 11:46 |
| dissonans | I think I only get some deprecation messages in bzr | 11:47 |
| dissonans | it's not practical for me to use Python 2.5 on Windows since I don't have the compatible compiler (VS .NET) installed | 11:48 |
| dissonans | I tried mingw, but that led to an obscure compilation error in bzr-svn | 11:48 |
| evarlast | dissonans: vs.net express is free and may work to compile python 2.5 | 12:28 |
| dissonans | evarlast: sure, but I don't feel like installing it | 12:31 |
| dissonans | I already have VS 2008 | 12:31 |
| evarlast | oh, it requires 2003 or 2005, but doesn't build with 2008? I see. I misunderstood. | 12:32 |
| dissonans | well, Python 2.5 is built with VS 2005 | 12:34 |
| dissonans | so I can't use VS 2008 with that version of Python | 12:34 |
| dissonans | basically I just want to be able to use Python 2.6 | 12:35 |
| tvainika | dissonans: why don't you install python2.6 for your own work, and python 2.5 for bzr(-svn)? i think you can install both in parallel | 12:44 |
| dissonans | tvainika: that's the problem I explained, I'm not able to compile bzr-svn for 2.5, unless I install VS 2005 | 12:45 |
| tvainika | dissonans: how about using installer package's bzr-svn? | 12:45 |
| dissonans | it's not usable with bzr 1.7.1 at least | 12:45 |
| dissonans | I tried | 12:46 |
| === mark1 is now known as markh | ||
| synic | is the lp: shortcut part of a configuration file or a plugin or something? | 14:47 |
| synic | can I add new ones? | 14:47 |
| dobey | synic: i think it's from the launchpad plug-in | 14:54 |
| synic | dobey: ah, thanks | 14:55 |
| luks | synic: you might find bzr-bookmarks useful | 14:55 |
| synic | sweet :) | 14:55 |
| luks | synic: it will not allow you to add prefixes like foo:bar but instead bm:foo/bar | 14:56 |
| luks | not as nice, but does the job | 14:56 |
| synic | good enough :) | 14:56 |
| jam | Verterok: ping | 14:56 |
| Verterok | jam: pong | 14:56 |
| Verterok | jam: reading the mail ATM | 14:58 |
| jam | Verterok: I just uploaded the update-site stuff, did you get a chance to look at it? | 14:58 |
| Verterok | jam: thanks, the version part is just to identify the archive, would be ok if I create a new archive to upload, I just remembered I need to change a xml inside the archive to link to the new url :/ | 14:59 |
| jam | Verterok: no, now that we have an update site, you are forbidden from ever updating it :) | 15:01 |
| jam | sure, whatever you need | 15:01 |
| jam | to get it to work | 15:01 |
| Verterok | hehe | 15:01 |
| Verterok | ok, I'll let you know when I finish updating the zip. Thanks! | 15:02 |
| jam | Verterok: if possible, can you create a tarball? It turns out that machine doesn't have zip tools | 15:03 |
| Verterok | jam: sure, np | 15:03 |
| persia | Good day. I have a branch of a project. I recently did a `bzr pull`, and received the message "All changes applied successfully". I also appear to have a file with the ".OTHER" extension that would have come from a conflict at one point. | 15:41 |
| persia | Is there a way to determine when the conflict occured, and whether it still conflicts, or how? | 15:42 |
| luks | run `bzr status` to see if it's still a conflict | 15:43 |
| persia | That reports a conflict. | 15:44 |
| persia | How about determining when? | 15:44 |
| persia | Also, should I be able to bzr pull with a success message with a pending conflict? | 15:44 |
| luks | I'm not sure how is behaves if there is a conflict and you pull to the branch | 15:45 |
| dobey | persia: i would guess that "bzr pull" gives you a success message when there are no new conflicts | 15:45 |
| persia | Mostly I'm confused about how I got into this state, and while I know I don't have any changes in the branch that are important, the apparent success message from bzr pull surprises me in the face of a conflict. | 15:45 |
| luks | if the pull causes a conflict it would probably say so | 15:45 |
| dobey | like, all the new merges were successful | 15:45 |
| persia | dobey, That makes sense, although it's a little confusing if one has a branch that one uses to track development done by others which somehow gets out of sync. | 15:47 |
| dobey | sure | 15:47 |
| persia | For my case, it's just a matter of removing everything and getting back in sync, but I wonder if this is intentional, or if bzr ought provide some warning that things are still not in sync. | 15:47 |
| dobey | you probably overlooked a conflict | 15:48 |
| dobey | and then did another pull | 15:48 |
| luks | the only way pull can conflict is if you have uncommitted changes | 15:48 |
| persia | dobey, Right. Based on the output of bzr status, that appears to be what happened. | 15:48 |
| dobey | wouldn't just doing a revert on the conflict fix your problem? | 15:48 |
| persia | dobey, perhaps. I'm not concerned much with fixing my branch. It becomes useless for me in two days, and is not expected to change in the meantime :) | 15:49 |
| dobey | i mean, instead of "removing everything and getting back in sync" | 15:49 |
| persia | And luks explained how to determine that I was indeed in a broken state, so as a user, I'm informed. | 15:49 |
| dobey | a simple revert should put you "back in sync" | 15:49 |
| dobey | right | 15:50 |
| persia | So, is this a usability issue? Should bzr say something when there is a successful pull into an unclean environment, or are users expected to know when the environment is unclean anyway? | 15:50 |
| Peng_ | Right, "revert" will get you back in sync, though it'll probably leave some garbage files around. | 15:51 |
| dobey | well, revert + resolved then :) | 15:51 |
| Peng_ | If you revert, there's no need for resolved. | 15:51 |
| dobey | well, resolved gets rid of the .STUFF files | 15:51 |
| luks | except that after revert is has no conflicts to resolve | 15:52 |
| luks | so the .STUFF files are just random unknown files | 15:53 |
| Peng_ | Oh, revert leaves behind the .STUFF files? | 15:53 |
| persia | Well, they are listed as random unknown files in bzr status now. | 15:53 |
| dobey | well, you can resolved, and then revert | 15:53 |
| Peng_ | Well, I guess it makes sense. | 15:53 |
| dobey | if you just revert, you'll have to rm them by hand i guess | 15:54 |
| dobey | would probably be good for bzr revert to do the right thing if the file is a conflict, though | 15:54 |
| persia | So I should file a bug asking bzr to do the right thing? | 15:54 |
| persia | And what is "the right thing"? | 15:54 |
| persia | I'd be happy with just telling the user that the pull succeeded, but there was still a conflict, but I'm not sure if that's "right". | 15:55 |
| dobey | well, if the file is in conflict when you do a revert, it should revert and get rid of the extra data files created by the conflict merge | 15:55 |
| dobey | ie the .STUFF | 15:56 |
| dobey | so there are 2 issues, bzr pull doesn't give you status of existing conflicts not created by the new merge | 15:56 |
| dobey | and bzr revert conflictedfile, leaves the conflictedfile.STUFF files around | 15:57 |
| luks | I think it should refuse to pull into a tree with conflicts | 15:58 |
| dobey | that's one way to resolve the issue, sure | 15:58 |
| dobey | it could say "N conflicts created by this merge, M already existing conflicts" also | 15:59 |
| dobey | i think either solution is fine | 15:59 |
| Peng_ | dobey: By default, revert doesn't destroy irreplaceable data. I bet that's why it ignores the .STUFF. | 16:00 |
| Peng_ | If it just leaves them all behind, someone should make it smarter, but I bet that's the reasoning and it's just that nobody has gone to the effort. | 16:00 |
| persia | Peng, Does bzr understand .STUFF well enough to be able to remove when one reverts to before the conflict? | 16:00 |
| Peng_ | persia: I dunno. | 16:01 |
| persia | Because revert-to-trunk with pending conflicts may be fairly unpredictable. Works for my use case, but I suspect my situation is rare : most people would be intentionally changing files. | 16:01 |
| dobey | the reasoning is probably "nobody thought to make it smart for conflicts" yeah | 16:02 |
| persia | So there are two bugs? One about notification on pull into a conflicting tree, and the other about dealing with .STUFF on revert? | 16:02 |
| dobey | i think so | 16:03 |
| * Peng_ mumbles | 16:03 | |
| persia | I have the knowledge to file the first one, but I have insufficient information for the second one. Could someone else file it? | 16:03 |
| Peng_ | I just tested it. 'bzr revert' does nuke the .STUFF. | 16:04 |
| Peng_ | It even nukes the .STUFF if they've been modified, which is probably a bad thing. | 16:05 |
| dobey | why would anyone modify the .STUFF? | 16:07 |
| persia | dobey, partial work to resolve the conflict, interrupted by a meeting, and forgotten overnight, for the user running bzr pull drinking their morning coffee ? | 16:08 |
| dobey | you don't just edit the actual file? | 16:09 |
| Peng_ | What persia said. | 16:09 |
| persia | dobey, Dunno. Personally, I tend to resolve conflicts in a fairly complex web of temp files and patches, but that's probably not the expected behaviour. | 16:10 |
| Peng_ | Occasionally, if there are severe conflicts, I might edit one side's changes into a .STUFF file instead of dealing with the conflict markers. | 16:10 |
| dobey | but if you forgot about the conflict, would you do "bzr revert conflictedfile"? | 16:11 |
| dobey | or would you do the bzr pull as you said? | 16:11 |
| persia | Conflict markers are often annoying. Even for a trivial change of a certain class, I'll use "diff foo.BASE foo.THIS > foo; cat foo.other >> foo; vi foo". | 16:11 |
| dobey | it seems unlikely that someone would bzr revert willy nilly in your use case. and if bzr pull failed/warned about the conflict, they would probably investigate or remember they were working on it, no? | 16:12 |
| Peng_ | dobey: Realistically, this all probably wouldn't happen to me. | 16:12 |
| Peng_ | dobey: But that doesn't mean revert's behavior shouldn't be improved, just that it's low priority. | 16:12 |
| * Peng_ goes back to being away. | 16:12 | |
| dobey | sure | 16:12 |
| Peng_ | (lunch!) | 16:12 |
| * dobey needs to get lunch as well | 16:13 | |
| persia | notification should resolve 80% of the potential confusion. The rest is just enhancement | 16:13 |
| Verterok | jam: I just mailed the tarball, thanks! | 16:15 |
| === Verterok is now known as Verterok|lunch | ||
| persia | Thanks for listening. Please change the contents of 290350 if I have inaccurately described the desired change. | 16:21 |
| sven | hi! i'm using the current dev branch of bzr and the current dev branch of bzr-gtk. when running 'bzr gci', i can't enter per-file comments. the text box to enter them does not show up when i click on a file name | 16:52 |
| sven | is this a known issue? | 16:52 |
| Peng_ | sven: Uh, someone (you?) mentioned this yesterday. | 16:55 |
| Peng_ | Or the day before. I dunno. | 16:55 |
| Peng_ | sven: I don't know what came of it. | 16:55 |
| sven | Peng_, i've mentioned it, but didn't see any reply | 16:55 |
| Peng_ | Ah. | 16:55 |
| Peng_ | You might get more attention if you filed a bug. Shrug. | 16:55 |
| sven | Peng_, ok, just thought i'd ask more informally before doing that. | 16:57 |
| jelmer | sven, afaik you have to enable them explicitly | 16:57 |
| Peng_ | sven: You're right, but if that isn't working... | 16:57 |
| Peng_ | Oh, ok. :) | 16:57 |
| sven | jelmer, how do it enable per-file comments explicitly? | 16:58 |
| jelmer | sven: did you set per_file_commits to true in the config? | 16:58 |
| sven | jelmer, hmm, no it's off. that should explain it. i have no idea why it always worked before | 16:59 |
| sven | jelmer, it works now. thanks! | 16:59 |
| Peng_ | That was a quick fix. :) | 17:02 |
| === gour` is now known as gour_ | ||
| === gour_ is now known as gour | ||
| === BasicPRO is now known as BasicOSX | ||
| === abentley1 is now known as abentley | ||
| === tetha_ is now known as tetha | ||
| === Verterok|lunch is now known as Verterok | ||
| === Verterok is now known as Verterok|out | ||
| ronny | hi | 20:19 |
| ronny | i think i missused bzr svn-import - used it on some svn, now i got a repo with no branches - is there a way to get a branch, or should i restart different | 20:21 |
| Peng_ | ronny: ...What do you mean "no branches"? There's nothing but a .bzr directory? If you mean that the branches don't have working trees, use "bzr co" inside a branch to create it. | 20:26 |
| ronny | Peng_: there is no branch | 20:27 |
| lifeless | ronny: can you run 'bzr branches' | 20:28 |
| ronny | no | 20:29 |
| Peng_ | That's part of bzrtools. | 20:29 |
| ronny | hmm, dammit - i just noticed im also still on bzr 1.6 from intrepid | 20:29 |
| ronny | bzr branches has no output | 20:30 |
| ronny | ls .bzr/ -> "branch-format branch-lock README repository svn-import-revision" | 20:30 |
| ronny | hmm, ok, i retry with bzr clone now | 20:34 |
| luks | I wish somebody would remove the clone and get aliases from bzr branch | 20:35 |
| jelmer | ronny, if you want to import a single branch, use "bzr branch" rather than "bzr svn-import" | 21:08 |
| seb_kuzminsky | hi folks, can launchpad show me a merge history like this: | 21:10 |
| seb_kuzminsky | http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/tp.c?graph=1 | 21:10 |
| ronny | jelmer: ok | 21:10 |
| seb_kuzminsky | i want to see the history of a file: on which branches were commits to this file made? | 21:19 |
| seb_kuzminsky | is that in bzr or launchpad somewhere? | 21:19 |
| dobey | bzr-gtk has some sort of merge graph display thing, that might do what you want | 21:20 |
| seb_kuzminsky | "bzr graph-ancestry" is pretty close | 21:21 |
| seb_kuzminsky | is there a view like that on lp? | 21:21 |
| asabil | seb_kuzminsky: try "bzr vis" | 21:21 |
| seb_kuzminsky | graph-ancestry seems to have an html output mode... | 21:21 |
| dobey | i don't think lp has graphing stuff like that | 21:21 |
| seb_kuzminsky | asabil ftw! | 21:21 |
| seb_kuzminsky | thanks :-) | 21:22 |
| seb_kuzminsky | now if only lp had something like that so I could easily show the CVS folks i'm trying to convert to bzr ;-) | 21:22 |
| asabil | seb_kuzminsky: you can always give an url to bzr vis | 21:23 |
| asabil | bzr vis lp:~user/project/branch | 21:23 |
| seb_kuzminsky | right... they dont have bzr installed, i'll take a screenshot of bzr vis on my machine and show them that | 21:25 |
| seb_kuzminsky | they're still in this "central server does everything" mindframe... | 21:25 |
| dobey | well, lp is just a central server | 21:26 |
| dobey | but it's a tools thing. they are all just tools. some are better than other for somet things :) | 21:27 |
| dobey | i still prefer svn for various things | 21:27 |
| seb_kuzminsky | they're comparing lp to cvsweb, which provides a web interface pretty similar to "bzr vis" | 21:27 |
| seb_kuzminsky | http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/tp.c?graph=1 | 21:27 |
| seb_kuzminsky | with mouse-overs and links and stuff, it's pretty good | 21:28 |
| dobey | eh | 21:28 |
| seb_kuzminsky | <shrug> | 21:29 |
| lifeless | so I think someone should file a bug on loggerhead for a per-file view | 21:30 |
| seb_kuzminsky | sure, i'll be happy to do that | 21:30 |
| seb_kuzminsky | hm, "bzr vis" is confusing me a bit | 21:35 |
| seb_kuzminsky | i thought the color of the dot represented the branch, but that doesnt seem to be the case | 21:35 |
| === BasicTheProgram is now known as Basic | ||
| seb_kuzminsky | lifeless: ok i filed the bug: https://bugs.launchpad.net/loggerhead/+bug/290475 | 21:43 |
| ubottu | Ubuntu bug 290475 in loggerhead "please add a per-file view of ancestry" [Undecided,New] | 21:44 |
| seb_kuzminsky | heh | 21:44 |
| lifeless | thanks | 21:44 |
| lifeless | mneptok: btw | 21:44 |
| lifeless | mneptok: I haven't heard boo about the search stuff | 21:44 |
| === Mathilda is now known as uws | ||
| poolie | hullo bzristas | 21:51 |
| lifeless | I'll have a long black | 21:51 |
| === BasicPRO is now known as BasicOSX | ||
| Rolly | Anyone know if nested branch support is still being worked on? | 22:28 |
| HomingHamster | hello everyone | 22:31 |
| HomingHamster | i'm running mac 10.5, i've installed bzr from the mac install package. and i've also installed the eclipse plugin by adding it a s an update site in eclipse. the only thing is, i can't fnid where bazaar has been installed. whereis bzr returns nothing. | 22:33 |
| HomingHamster | wow, pretty quiet... | 22:34 |
| HomingHamster | am i missing some major thing? | 22:35 |
| mlh | BasicOSX: ^^ | 22:42 |
| mlh | I don't know whether there many OS/x users here | 22:42 |
| BasicOSX | I run bzr from bzr | 22:42 |
| BasicOSX | I did not install it from package I got it via bzr it's self | 22:43 |
| BasicOSX | but it should be in /usr/local/bin/ | 22:43 |
| mneptok | lifeless: weird. the Codethink guys really wanted to see you in Boston. | 22:43 |
| BasicOSX | Which is a symlink to /Library/Frameworks/Python.framework/Versions/ | 22:44 |
| lifeless | mneptok: huh | 22:45 |
| === lifeless_ is now known as lifeless | ||
| lifeless | just had a power brownout :( | 22:58 |
| lifeless | vila: hi | 22:58 |
| === ubott2 is now known as ubottu | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!