| glyph | since I show up periodically to complain I figure I should stop by to say something nice too | 00:11 |
|---|---|---|
| glyph | I have been working this week using bzr and rebase rather than working in svn branches | 00:11 |
| glyph | and it has been fantastic. | 00:12 |
| glyph | it has improved the quality of my development experience significantly. | 00:12 |
| glyph | (now go fix all those bugs plz) | 00:12 |
| spiv | Hooray! | 00:13 |
| mkanat | glyph: That's awesome! | 00:14 |
| spiv | jelmer: hey, the daily builds PPA looks nice! | 00:15 |
| jelmer | spiv: Thanks :-) | 00:16 |
| glyph | One thing I'm wondering about: is rebase supposed to be able to 'fix' merges that have gone in the other direction? | 00:16 |
| lvh | Hi. | 00:35 |
| lvh | Can anyone reccomend any good bzr-supporting project management packages that I can host in-house? | 00:36 |
| lvh | I tried redmine, but it doesn't do multiple branches -- there's a patch, but that's basically broken. | 00:36 |
| spiv | lvh: trac, maybe. | 00:40 |
| lvh | spiv: :-( | 00:41 |
| lvh | spiv: I was hoping you weren't going to say that, but okay | 00:41 |
| spiv | lvh: there's also Launchpad | 00:42 |
| lvh | spiv: I was under the impression lp is not something you're supposed to host in-house. | 00:42 |
| lvh | (supposed to being distinct from 'possible') | 00:42 |
| spiv | Well, I wouldn't really recommend it. | 00:43 |
| spiv | Hard to say if the effort of deploying something as overkill as LP is better or worse than Trac ;) | 00:43 |
| lvh | spiv: honestly I'd just use fossil if there was a bzr-fossil | 00:45 |
| lvh | spiv: also http://trac-hacks.org/wiki/PeerReviewPlugin/Documentation C-f "to be written" | 00:45 |
| spiv | lvh: hmm, for code review specifically there may be options | 00:48 |
| spiv | I wouldn't be surprised to find that reviewboard or something has bzr support. And there's also BundleBuggy, which bzr used to use before Launchpad. | 00:49 |
| lvh | spiv: I had forgotten about bb, thanks | 00:50 |
| mkanat | lvh: Bugzilla isn't a PM system, but it does have a VCS extension that supports bzr. | 01:13 |
| spiv | mkanat: ooh, that's good to know | 01:15 |
| mkanat | Yeah, http://code.google.com/p/bugzilla-vcs/ | 01:15 |
| mkanat | I just did another release of the VCS extension today, in fact, partially to improve bzr support. | 01:15 |
| spiv | Yay :) | 01:17 |
| lifeless | \o/ | 01:17 |
| mkanat | :-) | 01:18 |
| jbowtie | jelmer: bzr-tfs in trunk supports CodePlex. | 01:18 |
| mkanat | And I'm pretty sure that my Perl module on CPAN is still the only Perl interface to bzr. | 01:18 |
| jbowtie | So hopefully I'll be able to release that this weekend. | 01:20 |
| glyph | is there a way to ask, during an interrupted rebase, 'what was the commit message for the revision that I am fixing conflicts on'? | 01:47 |
| GungaDin | are there any diagnostic tools for criss cross merges? how can I know why and for which files they're caused? | 02:24 |
| === oubiwann-away is now known as oubiwann | ||
| spiv | GungaDin: bzr qlog | 03:05 |
| spiv | GungaDin: (or 'bzr viz' if you prefer bzr-gtk to qbzr) | 03:05 |
| GungaDin | that doesn't tell me what file(s) specifically it was caused by.. does it? | 03:10 |
| fullermd | What do you mean by "caused by files"? Criss-cross refers to the revision history... | 03:11 |
| GungaDin | yeah, but the revision history contains the history of file/dir changes, no? | 03:12 |
| fullermd | I suppose. It just seems like a weird way of looking at things. | 03:13 |
| GungaDin | why's that? | 03:13 |
| fullermd | I mean, you could build a of all the revisions at and after the cross, then list all the files that got changed, but what would that tell you? | 03:13 |
| GungaDin | I just want to know why a criss cross is caused. | 03:14 |
| GungaDin | what caused it. | 03:14 |
| fullermd | It's not caused by any files, it's caused by the shape of the revision history. | 03:14 |
| GungaDin | fine, then at which point that shaped changed to cause it. | 03:15 |
| spiv | Right, that shape is the revision graph, and that's what qlog/viz show you. | 03:16 |
| fullermd | I don't know of anything existing that can spit out "these are the crossed merges". You can often spot them in something like qlog/viz if the affected area is small enough that they're nearly-enough on screen together. | 03:16 |
| fullermd | If it spans enough revisions, it gets messy trying to parse visually. | 03:16 |
| spiv | Yes, it would be nice to add something that can help users see and understand where the criss-cross happened. | 03:18 |
| fullermd | I s'pose to somebody reasonably conversant with bzrlib, it would be fairly straightforward to rip out the bits of the 3-way merger that detect the cross to make a lister. | 03:18 |
| spiv | Well it's basically just Graph.find_lca (or Graph.find_unique_lca if you want to force bzr to find just one... the hidden find-merge-base command calls this) to identify the revisions. | 03:22 |
| spiv | But you'd also want to somehow describe which edges crossed, I think. | 03:22 |
| * fullermd wishes revctrl.org were actively curated :| | 03:27 | |
| * spiv too | 03:30 | |
| ultramage | hello, I wanted to try out Bazaar (windows, standalone). I installed it, ran 'bzr', then 'bzr help commands' to see what options there are. | 09:47 |
| ultramage | and I got bzr: ERROR: Bazaar Explorer requires QBzr. Please install QBzr (https://launchpad.net/qbzr). | 09:48 |
| ultramage | why does 'bzr help commands' tell me to install a GUI component that I don't want? | 09:48 |
| ultramage | if it's a mandatory component before you can actually use the software, then include it in the base distribution | 09:51 |
| ultramage | I will wait until you people wake up and are able to answer my questions | 10:00 |
| jelmer | ultramage: It looks like you have bzr-explorer installed but not one of its dependencies, qbzr | 10:09 |
| jelmer | ultramage: Did you install bzr-explorer, perhaps as part of the windows install? | 10:10 |
| ultramage | ah, I see, that would be it | 10:10 |
| ultramage | I can't recall seeing Qbzr as one of the options... but installing it separately solved that | 10:10 |
| ultramage | it's weird that the commandline tool would just outright refuse to run, instead of failing gracefully and just displaying a subset of the commands or something | 10:11 |
| Tak | doesn't the windows installer include bzr-explorer and all the deps? | 10:11 |
| Tak | at least, it Worked For Me | 10:11 |
| ultramage | lemme re-run it and see if I unchecked anything obviously vital | 10:11 |
| jelmer | arguably it shouldn't let you install a combination of plugins that won't work, but I'm not sure how hard it is to forbid that in the windows installer | 10:13 |
| ultramage | yes, I see now | 10:13 |
| ultramage | I picked the bazaar explorer gui, but unchecked the qbzr plugin at the very bottom | 10:14 |
| ultramage | "dialogs for gui applications and IDEs" | 10:14 |
| ultramage | (doesn't say 'vital component of bzr commandline utility' though) | 10:14 |
| ultramage | I guess that it's a component interaction issue | 10:14 |
| ultramage | anyways, that's solved from my point of view | 10:14 |
| ultramage | now to the questions... I'm looking to replace an existing version control application that I've been using so far, and I've got a few quick questions about Bazaar features, if you don't mind | 10:15 |
| ultramage | * must each bazaar branch directory (which I consider a 'checkout') store its own clone of the repository it's using? | 10:16 |
| Tak | from which vc are you coming? ;-) | 10:17 |
| ultramage | svk | 10:17 |
| Tak | ok | 10:17 |
| ultramage | because what I'm doing right now is having the upstream repositories mirrored at a central location on a network share, and just doing lightweight checkouts against those (basically, a small directory with a human-editable config file) | 10:18 |
| Tak | a bzr branch by default contains all the history for that branch | 10:19 |
| Tak | what is it that you /want/ to do? | 10:19 |
| LenZ | ultramage: bzr supports "lightweight" checkouts | 10:19 |
| ultramage | well, for example, make four checkouts of the target directory | 10:20 |
| ultramage | without having the entire history mirrored four times | 10:20 |
| LenZ | ultramage: Take a look at "shared repositories" as well, to save disk space. | 10:20 |
| ultramage | mmm okay :) | 10:20 |
| Tak | if you create a shared repository locally, then branch into that, you'll get what you want | 10:20 |
| ultramage | which part of documentation does this fall into? | 10:21 |
| Tak | http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/organizing_your_workspace.html | 10:23 |
| ultramage | :) | 10:23 |
| ultramage | a suitable name | 10:23 |
| Tak | the "feature branches" section seems relevant | 10:23 |
| ultramage | hmm, 'bzr branch' and 'bzr checkout' seem to have produced the same result | 10:24 |
| Tak | branch gives you an unbound branch which you can manipulate locally | 10:25 |
| ultramage | ah | 10:25 |
| Tak | checkout gives you a bound branch that requires connection to the remote server for most operations (very similar to an svk checkout) | 10:25 |
| ultramage | no, svk checkout requires a local mirror to be available | 10:25 |
| ultramage | er, prepared | 10:25 |
| ultramage | so basically, the difference between a checkout and a branch is that you're not supposed to commit directly into a checkout? | 10:26 |
| ultramage | (in svk, when doing a commit, it sends it to the remote repository, syncs the local mirror and then pulls the changes from there) | 10:27 |
| Tak | the difference between a checkout and a branch is that commits to a checkout are immediately pushed to the remote repo | 10:28 |
| ultramage | does the write first happen to the checkout, or to the remote repo? | 10:29 |
| ultramage | maybe I should try it out more first... I'm still not at a point where I could say "yes, this is what I want to use" | 10:30 |
| ultramage | I guess I'm still thinking in terms of one central svn repository | 10:31 |
| maxb | IIUC checkouts provide a firm guarantee that the commit will not actually happen locally unless it succeeded remotely | 10:35 |
| ultramage | what's pretty confusing is that I'm not used to thinking in terms of branches... most of the time, when I work on something, I have the entire repository mirrored and ready for access, not just one branch | 10:36 |
| ultramage | yes, that would be good :) | 10:36 |
| maxb | ultramage: Yes that is one of the philosophical quirks of Bazaar relative to other VCSes - to Bazaar, a branch is the primary object. That several might be stored near to each other in a wider repository is a mere detail | 10:38 |
| maxb | Which is quite a contrast to git | 10:39 |
| ultramage | so far I've been using a particular feature of svk, where if you make a dedicated mirror of the root, the revision numbers will align | 10:40 |
| ultramage | so later on when you run svk annotate, or even just svk info, if it says r12345 you know you're talking about r12345 | 10:40 |
| ultramage | does bzr have the concept of sequential revision numbers? | 10:40 |
| ultramage | Lamport clock and all that stuff | 10:41 |
| ultramage | I read the 'feature branches' guide but haven't understood the concept | 10:44 |
| ultramage | I don't think that's what I'm looking for... or the examples used there don't demonstrate it | 10:45 |
| spiv | Yes, each branch has sequential revision numbers (but they aren't in general comparable between different branches) | 10:45 |
| ultramage | that's okay if I can treat an entire repository checkout as a single brnach | 10:46 |
| ultramage | (which it seems I can) | 10:46 |
| ultramage | the feature branches example seems to imply a way to start a branch from another branch... not exactly sure | 10:47 |
| ultramage | confusion levels are high :) | 10:48 |
| maxb | "Lamport clock" ? | 10:48 |
| maxb | OK, so first important thing - if you import svn into bzr via bzr-svn, each imported revision tracks the svn revno it came from (and this is displayed in bzr log) | 10:49 |
| maxb | I'm a bit confused by what you mean by "treat an entire repository checkout as a single brnach" | 10:50 |
| spiv | ultramage: basically feature branches mean to do a new set of work on your code you: start a new branch (from the current version of your 'trunk', usually), perform the work on that branch (for however long it takes, minutes, days, months...), then when it is finished you merge the entire set of changes from that branch back into the original branch. | 10:51 |
| spiv | ultramage: this avoids having half-done work on your main branch, where it can break things and interfere with other people trying to work on that code. | 10:51 |
| maxb | By definition, a (non-lightweight) checkout *is* a branch - there is no "treat as" | 10:52 |
| spiv | ultramage: as a logical extension of that, if during that feature branch there's some smaller feature that needs to be done, you can make a new feature branch for *that* (based off the first feature branch, or off trunk, depending on what suits you best) | 10:53 |
| spiv | ultramage: e.g. everytime I start working on fixing a bug in bzr, I first make a new branch of bzr, and do that work in that branch. | 10:53 |
| ultramage | in svk you can mirror into a subdirectory (mirrored branch) and make local branches next to them... and since they're all in a single local depot, you can merge across them | 10:54 |
| ultramage | however I don't use that feature | 10:55 |
| spiv | Right, bzr can merge between any branches that share history (regardless of whether they share a repo). | 10:55 |
| maxb | ultramage: With bzr, think of the entire filesystem as your depot | 10:55 |
| ultramage | if I have two independent things going on at the same time, I just make two quick checkouts | 10:55 |
| spiv | ultramage: now imagine you can make multiple commits in those checkouts before those changes affect the original repo | 10:56 |
| ultramage | I guess that approach is good if you want to make a bunch of local commits before you're done with everything | 10:56 |
| ultramage | so I guess this is to avoid making a publicly visible dev branch in the remote repository | 10:56 |
| spiv | Right, exactly. If you only ever need a single commit to make a complete change ready for the main line of development that everyone is working on, then you don't need feature branches. But if you e.g. want a development process where you develop a change, then it goes through code review or QA, then maybe gets further changes due to that, then a feature branch starts making lots of sense. | 10:57 |
| ultramage | I have not used this approach because the extra commits make your local revision numbering go out of sync | 10:57 |
| spiv | Well, using feature branches is orthogonal I think to whether you make the work-in-progress visible. Certainly you can use them like a checkout that you don't share until its done, but you can also share your work-in-progress with them (rather than sharing it via landing half-done work on your trunk). | 10:58 |
| ultramage | (so when I ran svk annotate later, I'd get local numbers instead of the remote ones... and even if I did get remote ones, I'd still have to figure out what the matching local ones are0 | 10:58 |
| ultramage | maybe bazaar tracks revision numbers for each branch individually and this is not an isuse | 10:59 |
| spiv | bzr has sequential revision numbers for convenience, and (although you rarely need to use them directly) unique revision IDs for when you need to refer to a revision independently of where it is in any individual revision history. | 11:00 |
| spiv | Yes, a revision number is a per-branch attribute. | 11:00 |
| ultramage | okay | 11:00 |
| spiv | It's always "revision number X in branch Y" | 11:00 |
| ultramage | hmm, question; if I check out http://svn.something.com/trunk, will my checkout's .bzr/repository directory only store data for the trunk branch? | 11:01 |
| ultramage | I guess that's easy enough to test :D | 11:02 |
| ultramage | yep, it does | 11:02 |
| ultramage | so if I ever lose network connectivity and have the need to look anywhere past that branch, I'm out of luck | 11:02 |
| spiv | You can use 'bzr init-repo' to make a shared repository; branches created under that directory will then share revisions. | 11:02 |
| spiv | Or you can use 'bzr svn-import' to just mirror the whole SVN repo in one go. | 11:03 |
| spiv | (and it takes care of making a shared repo for you) | 11:03 |
| ultramage | I'll look at that :) | 11:03 |
| ultramage | well, it looks exactly like a checkout, without the checkout :) | 11:05 |
| ultramage | well, and it doesn't have the 'bound' attribute and has 'no-working-trees' and 'shared-storage' | 11:07 |
| spiv | You can make a checkout with "bzr checkout BRANCH_DIR CHECKOUT_DIR". If they're both on disk you can use --lightweight to avoid making a new copy of the revision history. If you like, you can do "bzr co ." in the branch directory itself to just make the checkout at the same dir as the branch. | 11:07 |
| spiv | Right, svn-import makes "branches" i.e. copies of the original repo, rather than checkouts bound to the original repo. | 11:08 |
| ultramage | hmm. | 11:09 |
| spiv | You could make checkouts directly from your SVN repo if you like in that repo made by svn-import. | 11:09 |
| ultramage | I'm thinking | 11:09 |
| spiv | They'll reuse the history store already present, but commit directly back to SVN. | 11:09 |
| ultramage | how about a bzr checkout of root, and then bzr checkout --lightweight of that checkout? | 11:09 |
| spiv | You'd have to fiddle with the settings of the bzr-svn plugin to make that work, it's not how bzr is designed. | 11:10 |
| ultramage | that's probably the closest thing I can think of to my current setup | 11:10 |
| spiv | I wouldn't recommend it, you'll be fighting bzr rather than working with it, and you're likely be dissatisfied with the result. | 11:11 |
| ultramage | so I've yet to actually set up my files for testing... this is not good | 11:11 |
| spiv | Why do you want a single tree containing the contents of every branch and tag (and trunk)? | 11:12 |
| maxb | checking out the root of a svn repository using bzr-svn is not at all what you want to do | 11:12 |
| spiv | The obvious reasons I can think of have better solutions. | 11:12 |
| ultramage | yes, I know that doing an actual checkout of a project with 1000 tags is nuts | 11:13 |
| ultramage | the idea of just putting a few select branches next to each other sounds nice | 11:13 |
| ultramage | earlier you said "svn-import makes "branches" i.e. copies of the original repo, rather than checkouts bound to the original repo." | 11:14 |
| ultramage | meaning that if I make a checkout of anything in there, and then commit from it, it will just corrupt my local imported data and never get to the original repo | 11:14 |
| maxb | uh? no | 11:15 |
| ultramage | I guess the main question is whether a commit operation into there is transitive | 11:15 |
| maxb | oh, I see. | 11:15 |
| ultramage | because starting an independent local fork of a project's central repository is not what I want to do :) | 11:16 |
| maxb | Right, you'd want to checkout from the upstream repository | 11:17 |
| ultramage | svk ensures I always have access to anything I need from the repository even when offline, so if I suddenly get the need to run svk annotate on some branch I normally did not check out, I can do that. | 11:18 |
| ultramage | plus there's also the upside that all svk depots are simple svn repositories and can be hooked up to anything that reads svn repositories | 11:19 |
| ultramage | the reason why I'm looking into bzr is that all svk development has halted years ago, it has data corruption issues on windows, it's perl-based and I never got it to actually install, and that none of the bugreports I submitted ever got taken care of | 11:21 |
| ultramage | plus it can't handle svn:externals | 11:21 |
| ultramage | ok, so first things first... is it possible to make two checkouts of the same remote branch, without occupying twice the disk space? | 11:22 |
| maxb | Sure - the best way to handle this is a bzr shared repository (created with init-repo). Any branches / checkouts you create below the directory inited as a repository will store their revision history in the repository, not within the branch/checkout itself | 11:23 |
| maxb | common data will be shared appropriately | 11:24 |
| ultramage | I just made a basic checkout of a branch, and then ran bzr annotate on it | 11:25 |
| ultramage | the revision numbers displayed are local to my checkout and have nothing in common with the original repository - so I cannot do anything with them unless I look them up in my checkout | 11:26 |
| ultramage | it's the exact same issue as I had with svk's local depot approach - it makes the revision numbers go out of sync | 11:27 |
| spiv | ultramage: if you look at the 'bzr log -r REVNO' for the bzr revision, it'll tell you the SVN revision | 11:27 |
| ultramage | spiv: that would get very tedious very fast | 11:27 |
| spiv | (it's possible that one of the GUI plugins like qbzr or bzr-gtk has integrated that into their annotate... it would make a nice improvement if it hasn't already been done) | 11:28 |
| ultramage | I guess this is why noone uses revision numbers anymore when talking about revisions | 11:28 |
| spiv | Hmm, I guess with qbzr's "bzr qannotate" when you click the line it shows you the revision in the lower pane, maybe that already includes the SVN revno | 11:28 |
| jelmer | Yes, qbzr's qlog will show you foreign revision ids. | 11:28 |
| spiv | (be nice to have an option to show the SVN revno in place of the bzr one though, I agree) | 11:28 |
| ultramage | when I see a bugtracker entry saying "fixed in r17005", how do I determine which one that maps to in my checkout? or whether my checkout is older or newer? | 11:28 |
| jelmer | loggerhead does as well | 11:29 |
| spiv | ultramage: well, you can do "bzr log -r svn:17005" or whatever to talk to bzr in terms of svn revnos | 11:29 |
| Tak | fewer people talk about revisions anymore because git and hg turned them into meaningless spam :-P | 11:29 |
| ultramage | ah. | 11:29 |
| ultramage | yes, it's why my first phase was throwing out all software that uses hashes | 11:30 |
| ultramage | no total ordering, not even partial | 11:30 |
| ultramage | I don't even want to imagine the hell it would be to do more complicated stuff without a GUI resolving those hashes for you | 11:31 |
| ultramage | maybe that's why big projects' bugs take so long to fix - the developers are busy figuring out which revision is which | 11:32 |
| spiv | Well, mostly you find it's enough to talk in terms of branch tips. | 11:32 |
| spiv | But it depends on exactly what you're doing, of course. | 11:32 |
| spiv | I wish that was the biggest problem with fixing bugs in large projects! | 11:33 |
| ultramage | :) | 11:33 |
| luks | there are projects without a mainline (e.g. linux), so I can see revision numbers not being useful there | 11:33 |
| ultramage | yes, but I guess they worked around that by having artificial release numbers and use them as checkpoints | 11:34 |
| ultramage | hah, even after checking out the root, the revisions are all shifted by 1, just like in svk | 11:37 |
| ultramage | that's why they added a special root mirroring depot type | 11:37 |
| ultramage | I guess this is the consequence of being able to add extra local branches into the same local repo as the mirrored data | 11:40 |
| ultramage | question - when you people refer to some previous revision in your commit message, how do you refer to it? | 11:44 |
| ultramage | do you open a second console window, ask bzr to look up the revision number you want, and copy-paste the revision id hash into your message? | 11:44 |
| luks | I personally almost never use revision IDs | 11:45 |
| luks | so, if necessary, I look up the revision number | 11:45 |
| ultramage | ah, I see | 11:45 |
| luks | I use append-only branches, so the numbers don't change once pushed to the central repository | 11:45 |
| ultramage | this could be another artifact of centralized version control | 11:46 |
| ultramage | usually when I'm fixing something, I leave a reference to the revision where the thing I'm fixing broke | 11:46 |
| maxb | ultramage: It seems to me you are placing a little too much importance on revnos | 12:03 |
| mgorny | hello | 12:12 |
| mgorny | is it possible to get a unique identifier of a bzr tree (or at least revno --tree) without enforcing network activity? | 12:13 |
| LenZ | ultramage: You may also want to look into tags for identifying specific changes. They are cheap in bzr. | 12:13 |
| === deryck_ is now known as deryck | ||
| === Meths_ is now known as Meths | ||
| rubbs | when trying to do a bzr st I get this error on a parent branch. http://paste.ubuntu.com/523884/ | 14:58 |
| rubbs | basically says the dirstate file appears to be corrupt | 14:59 |
| rubbs | the user was using bzr explorer when trying to merge files into this branch. He said he got a "Bad File Descriptor" error | 15:00 |
| rubbs | here are the relevant log entries: http://paste.ubuntu.com/523895/ | 15:08 |
| rubbs | think I figured it out. I moved .bzr/checkout to .bzr/checkoutOld, did a lightweight checkout in another dir and copied the new .bzr/checkout dir to the old location. seems to have worked. | 15:25 |
| vila | rubbs: That's indeed the blessed workaround | 15:26 |
| vila | rubbs: It would be nice to better understand how this happened though | 15:27 |
| rubbs | I'll dig around and find out if I can find more info for you. I'm not the one who had the issue, I'm just the janitor ;) | 15:27 |
| rubbs | but I'll see what I can find, if I get enough info I'll file a bug | 15:27 |
| rubbs | or add it to one of the others I found | 15:27 |
| vila | thanks | 15:28 |
| rubbs | np | 15:28 |
| radix | Is there yet a tool that watches a bzr branch for changes and sends notifications when it does (email, IRC, or whatever)? | 15:30 |
| jelmer | radix: Hi | 15:33 |
| jelmer | radix: Yeah, there was a daemon that does local branch monitoring and can send out emails. | 15:33 |
| radix | jelmer: nice | 15:45 |
| radix | jelmer: lp:??? :) | 15:45 |
| jelmer | radix: I'm not sure where it lives, it was developed by a debian developer so I'm not sure if it's on Launchpad | 15:48 |
| jelmer | radix: lp:bzr-hookless-email | 15:49 |
| radix | jelmer: sweeet, thanks. | 15:54 |
| radix | I'll probably hook up IRC notifications to that too | 15:54 |
| === adrian is now known as Guest51764 | ||
| Guest51764 | Is there a merge method that ignores content changes (add / delete)? Some muppet made a branch in SVN by copying the folder, then SVN-deleting the sources, then SVN-adding the tree back again | 16:01 |
| Guest51764 | Ohh, guest | 16:01 |
| === Guest51764 is now known as awilkins | ||
| jelmer | awilkins: no, there isn't anything like that (yet) | 16:03 |
| awilkins | So when you merge this revision, you end up with a shower of conflicts (everything) as all the files get moved out of the way to make way for the "new" ones | 16:03 |
| awilkins | git just works for this because it just views the before and after of the revision as the same content tree ; would there be a way to get around it by cherrypicking that revision and properly merging the rest? | 16:04 |
| awilkins | Probably not, the file-ids are not going to match... bah | 16:11 |
| === deryck is now known as deryck[lunch] | ||
| jelmer | awilkins: yeah, that's the main issue. We need a way to make file ids converge | 16:18 |
| rubbs | hrm... when I did the moving of checkout to chechout old thing. Now bzr explorer says there is no working tree. | 16:18 |
| jelmer | awilkins: Otherwise you'll have to use this other magic merge indefinitely | 16:18 |
| rubbs | fwiw I did copy a checkout into the .bzr directory from a lightweight checkout | 16:19 |
| vila | rubbs: you copy the whole checkout dir or only the dirstate file in there ? | 16:31 |
| vila | only the dirstate file is needed | 16:32 |
| rubbs | whole checkout, should I just have done the dirstate? | 16:32 |
| rubbs | oh, will fix that thanks | 16:32 |
| vila | hmm, I fail to see what would change though... may be you should restart bzr-explorer ? | 16:33 |
| rubbs | trying that now, as your suggestion didn't fix it. | 16:34 |
| rubbs | I'm going to try branching from it and see if I can see the second branch. | 16:35 |
| rubbs | if that works, I'll delete the original and branch to the original name | 16:35 |
| rubbs | and rebind as necessary | 16:35 |
| rubbs | weird. the new branch also reports as not having a working tree in B.E. | 16:37 |
| rubbs | but it does. | 16:37 |
| rubbs | should I try cleaning the tree and then doing a checkout? | 16:38 |
| rubbs | when trying to clean the tree I get a "Nothing to delete" message, but it's got a working tree. | 16:45 |
| rubbs | even weirder is that if I delete out the tree bzr st reports that i made changes by deleting everything out. | 16:46 |
| vila | you did restart bzr-explorer ? | 16:47 |
| vila | rubbs: Are you on windows ? | 16:48 |
| rubbs | vila: yes restarted bzr-explorer, and I'm on Ubuntu, my coworker is on Windows. my instance of bzr explorer tells me I have no working tree | 16:49 |
| rubbs | I've even tried branching directly from the branch it was bound too | 16:49 |
| rubbs | to* | 16:49 |
| * vila blinks | 16:50 | |
| vila | bzr info ? | 16:50 |
| rubbs | vila: http://paste.ubuntu.com/523949/ | 16:52 |
| rubbs | it's bzr version 2.2.1 btw if that makes a difference | 16:53 |
| vila | hmm, this shouldn't | 16:53 |
| rubbs | yeah I'm getting stumped too | 16:53 |
| vila | hmm, so I would try to trigger a dirstate update by doing some inocuous change | 16:54 |
| vila | oh, or a bzr update | 16:54 |
| rubbs | oh, i'll try that. (I should have thought about that | 16:55 |
| vila | hmm, if you can afford such an update that is | 16:55 |
| rubbs | all local network so shouldn't be a problem | 16:55 |
| rubbs | ah... looks like a lock needs to be broken | 16:55 |
| rubbs | I'll get him to do it as it's in his name. I'll let you know how it goes in a sec | 16:56 |
| vila | k | 16:56 |
| rubbs | k... got the lock broken, but bzr update still didn't fix BE problem. | 17:03 |
| rubbs | BE still says the branch has no working tree | 17:03 |
| rubbs | also, tried just did a "touch testing.txt" within the workign tree | 17:03 |
| rubbs | bzr st correctly says it's unknown, but BE still thinks there's no working tree | 17:04 |
| vila | rubbs: I'm lost :-/ Not being a BE user doesn't help iether :-/ | 17:05 |
| vila | rubbs: and you restarted BE after 'bzr st' saw the unknown right ? | 17:06 |
| rubbs | yeah I'm not either, but coworker is. So this is somewhat important to figure it out. | 17:06 |
| rubbs | yeah | 17:06 |
| * vila scratches head | 17:06 | |
| rubbs | I'll do it again just to make sure | 17:06 |
| * rubbs is banging his head against the desk. | 17:06 | |
| vila | because the problem disappears or because it's still there ? | 17:07 |
| rubbs | still here. now I've got some permission thing when I try to merge, but I think I can figure that out | 17:08 |
| vila | rubbs: you didn't copy the dirstate file between windows and ubuntu right ? | 17:14 |
| rubbs | right, I did all my surgery on ubuntu | 17:17 |
| rubbs | oh this is frustrating. I can browse the tree with bzr explorer, but hitting refresh still says the branch has no working tree | 17:19 |
| === deryck[lunch] is now known as deryck | ||
| benje | hello | 17:34 |
| benje | 17:34 | |
| benje | i am using savannah and i would like to get help in use of bazaar explorer | 17:34 |
| benje | i am creating local branch but when i try to run the command to internet branch i get tehe following message | 17:35 |
| benje | bzr ERROR : Not a branch: "bzr+ssh://benje@bzr.savannah/nongnu.org/gxinterface/branch". | 17:36 |
| benje | i cannot find the advanced in menu too as describ in documentation http://doc.bazaar.canonical.com/explorer/en/tutorials/foss-contribute.html | 17:37 |
| benje | to log in to my account (but maybe only for launchpad ) | 17:38 |
| benje | i try the command in terminal but i get the same error | 17:38 |
| maxb | You have a slash not a dot betweeen savannah and nongnu | 17:38 |
| benje | how can we link project to internet server with bzr-explorer as i can work locally and put it once verified on internet server ? thanks | 17:39 |
| benje | maxb: right, i get it but i do a mistake on copy here | 17:39 |
| benje | if i look to the savannah rep i see the .bzr | 17:40 |
| benje | so why it's telling me not a branch ? | 17:41 |
| maxb | I would imagine your URL is incorrect | 17:42 |
| benje | i use this from savannah maxb | 17:43 |
| benje | https://savannah.nongnu.org/bzr/?group=gxinterface | 17:43 |
| benje | bzr branch bzr+ssh://<membername>@bzr.savannah.nongnu.org/gxinterface/branch | 17:43 |
| rubbs | vila: ok, now this is weird. The windows guys are using bzr over an sshfs adapter (I'm going to change it so they use bzr+ssh from now on, as I think this was part of the problem). so on a whim, I mounted the drive to my local Ubuntu machine via sshfs, then I opened the "local" folder in B.E. and it seems to be working. | 17:45 |
| benje | maxb you are right | 17:45 |
| rubbs | but bzr+ssh:// does not work in B.E. at the same location. | 17:45 |
| benje | maxb: if i try to got with http to bzr.savannah.nongnu.org/gxinterface no such file | 17:46 |
| benje | ok rubbs but even i do this on terminal without explorer ;) | 17:47 |
| benje | i try your method | 17:47 |
| rubbs | benje: sorry was talking about my own problem not yours ;) | 17:47 |
| benje | rubbs: but this seems the same ;) | 17:47 |
| benje | to get access with bzr+ssh to a rep | 17:47 |
| rubbs | not exactly. I'm having problems with a dirstate file being corrupted by B.E. seems like you're having "not a branch" issues | 17:48 |
| benje | external dir | 17:48 |
| maxb | benje: It is not working because that project does not have any branch there on the savannah server | 17:51 |
| maxb | It just has a bare .bzr control dir with no content | 17:51 |
| benje | yes i create it and try to commit my rep maxb | 17:52 |
| benje | do you think i have to rsync first ? | 17:53 |
| benje | rsunc ok | 17:54 |
| benje | i don't understand what's happen :/ and what i am doing how can i make a brnahc on distant rep | 18:06 |
| benje | brnahc branch | 18:06 |
| benje | i just want to commit local to server | 18:18 |
| vila | rubbs: I think you got something there and using bzr+ssh is certainly preferred (sorry for te delay, I EODed) | 18:55 |
| rubbs | vila: yeah I think I'm going to try to kill the sshfs stuff and see if I can't do some magic with bzr+ssh. the problem is that it's the bzr+ssh that's not reporting the working tree correctly :/ | 18:56 |
| vila | rubbs: bzr+ssh is *not* supposed to handle working trees ! At least not today | 18:59 |
| rubbs | vila: ah, so what I need to do is get them to have a local one and bind it to the dev server? | 19:00 |
| vila | exactly | 19:00 |
| rubbs | I c. I'll get that done | 19:00 |
| rubbs | thanks for the advice | 19:00 |
| benje | bye this was the problem https://bugs.launchpad.net/bzr/+bug/659763 | 21:27 |
| ubot5 | Launchpad bug 659763 in Bazaar "bzr smart server can't handle UTF-8 user names, gives UnknownErrorFromSmartServer (affected: 1, heat: 15)" [Medium,Confirmed] | 21:27 |
| mbt | I think I must just be a moron, but I have a merge that resulted in a conflict (which honestly I have never had happen before). Is there somewhere online that explains what these conflict markers are and what they mean? The docs seem to skip that and just say that they're there. | 22:44 |
| dash | mbt: conflict means there's two possible outcomes for each block of conflicted text | 22:45 |
| dash | mbt: so one represents the change in the branch you're merging from, one represents the change in the branch you're merning into | 22:46 |
| mbt | Right. I understand the reason for the conflict. What I don't understand is the format of this thing. Which is which? What are the >>>>> and <<<<< and ===== supposed to actually tell me? | 22:46 |
| dash | the bit between >>>> and ==== is one block | 22:46 |
| dash | the bit between ==== and <<<< is the other. | 22:46 |
| dash | there are also .OTHER and .THIS files containing the entire contents of the conflicted files | 22:47 |
| dash | and potentially .BASE, depending on your options | 22:47 |
| mbt | I'm still not getting it. http://pastebin.com/MJdchVSu <-- what block is what? | 22:48 |
| mbt | Oops, incomplete paste, try this one: http://pastebin.com/VdCypxAg | 22:49 |
| dash | the first block (2-12) is what's from your tree | 22:49 |
| mbt | From which tree? There working copy being merged into? | 22:50 |
| dash | right | 22:50 |
| dash | the second, 12-34, is from the merged-in branch. | 22:50 |
| mbt | So that's as it was before the merge | 22:50 |
| dash | same for 36-37 and 37-55 | 22:50 |
| mbt | Line 35 is identical to both branches, then? | 22:51 |
| dash | right, it's not inside hte conflict markers | 22:51 |
| dash | a lot of editors provide support for this format; what do you use? | 22:52 |
| mbt | Emacs. But I wasn't understanding what I was seeing, and it's all sorts of colorful, and I just wanted to know what I was looking at before I went any further. | 22:52 |
| dash | mbt: so your modeline probably says SMerge | 22:52 |
| mbt | Now the options for keep this and throw that away make sense though. | 22:52 |
| dash | yep. hooray. | 22:52 |
| mbt | Yes, it is in SMerge minor mode. | 22:53 |
| fullermd | Well, technically, it doesn't mean it's identical. Just that it merged without conflicts. But in the case of a single line in the midst like that... | 22:53 |
| mbt | Thank you muchly for the explanation, dash! | 22:53 |
| dash | <3 | 22:54 |
| bob2 | smerge is super awesome, aside from the default fruit salad colours | 22:54 |
| mbt | lol, I don't know what the defaults are since I use a colored theme on my Emacs, but the yellow was painful to look at. | 22:54 |
| bob2 | I guess I mean 'the defaults are terrible and most color-themes don't fix it' | 22:56 |
| mbt | Whoo. I believe I have resolved all my conflicts successfully. | 22:56 |
| mbt | Hopefully, I don't run into that again... but I guess now the next time I do, I know what I am looking at. | 22:57 |
| GungaDin | how can I tell at what revision a line was deleted from a file? (I can see who initially wrote it with bzr qblame.. but not when it was deleted...) | 23:05 |
| mbt | That sounds like a problem that could be solved with bisection. | 23:06 |
| mbt | If you don't have it already, grab a hold of a copy of the bzr-bisect plugin (https://launchpad.net/bzr-bisect) and see if that does what you need. | 23:07 |
| mbt | You can give it a starting point and an ending point (essentially, a revision known to have the line you're looking for, and a revision known to not have that line) and then you can bisect until you find the first version that doesn't have it. | 23:07 |
| GungaDin | thx | 23:13 |
| dash | hmm | 23:23 |
| dash | i use bzr as a frontend to an svn repository and i'm trying to post diffs to a reviewboard instance. reviewboard seems to want svn style diffs, not bzr-style ones. i have seen mentions of an 'svndiff' plugin that might produce this, anbyody know where i can find it? | 23:24 |
| bob2 | http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html#svn-diff-style-patches ? (I dunno how reviewboard fits in) | 23:26 |
| dash | yeah i just saw that. | 23:27 |
| dash | trying it now | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!