| poolie | lifeless: i really think we need to work out what's happening with pqm runtimes? | 00:05 |
|---|---|---|
| poolie | :s/?// | 00:05 |
| === thumper_laptop is now known as thumper | ||
| === mwhudson__ is now known as mwhudson | ||
| mtaylor | hey all - I need some help with bzr internals... | 01:08 |
| mtaylor | I'm working on a post_push hook to send mail similar to a post_commit email | 01:08 |
| mtaylor | the problem I'm having is getting the approrpiate starting revision to send to log.show_log and show_diff_trees | 01:09 |
| lifeless | mtaylor: why not adapt the email plugin ? | 01:09 |
| mtaylor | lifeless: I did | 01:09 |
| lifeless | mtaylor: I'd be happy to review patches to make it do both/be configurable | 01:10 |
| mtaylor | lifeless: actually - I'd love to send in the patches... although I might have diverged a bit much at this point (need to go back and break things up into patches I can send in) | 01:11 |
| lifeless | mtaylor: there is result.old_revid and old_revno, and result.new_revid and new_revno | 01:11 |
| mtaylor | lifeless: if I remember correctly the problem I started out trying to solve, if I use result.old_revno, the log is one revision short | 01:11 |
| lifeless | mtaylor: so x..y is half open | 01:13 |
| lifeless | 0..1 includes 1 but not 0 | 01:13 |
| mtaylor | yes | 01:13 |
| mtaylor | so that sent me down the trail of trying to find the -1 given 0 | 01:14 |
| lifeless | mtaylor: do you want to show 0 tho ? | 01:14 |
| mtaylor | yes | 01:14 |
| mtaylor | since it's the first rev that is being pushed | 01:14 |
| lifeless | mtaylor: no, its the first rev before what is being pushed | 01:15 |
| lifeless | mtaylor: I think you might be seeing left-hand-history pivoting | 01:15 |
| mtaylor | what's that? | 01:15 |
| lifeless | say your current master branch is ABC | 01:15 |
| lifeless | and your local branch is AD | 01:16 |
| lifeless | (D is local work) | 01:16 |
| lifeless | you can't push | 01:16 |
| lifeless | so you merge, getting | 01:16 |
| lifeless | ADE | 01:16 |
| lifeless | E is a merge of BC | 01:16 |
| lifeless | now when you push to the master branch the master becomes | 01:16 |
| lifeless | ADE | 01:16 |
| mtaylor | right | 01:16 |
| lifeless | and the old_revno == 3 | 01:16 |
| lifeless | new_revno == 3 | 01:16 |
| lifeless | because the old_revno is not the old revision number of the old revid in *your branch*, its the old revno of the old revid in the untouched target | 01:17 |
| mtaylor | ok. makes sense | 01:17 |
| lifeless | this is one of the reasons that I recommend centralised branches be mutated via checkouts rather than pushing | 01:18 |
| lifeless | because checkouts help manage the workflow to avoid this | 01:18 |
| lifeless | there is also a branch flag you can set to tell bzr to error if this would happen | 01:18 |
| lifeless | the left hand history is privileged in a number of ways, its what log --line shows | 01:18 |
| lifeless | its usually the representative list of 'what a project has merged' | 01:19 |
| mtaylor | so what I need in this case is really a pre-push hook that gathers info in the same way as bzr send does | 01:19 |
| lifeless | well, if you *want* such pivots in your workflow, yes. | 01:19 |
| lifeless | but anyhow - the first thing I would do is examine your test case to see if this is what is happening | 01:20 |
| mtaylor | bzr push -r50 /tmp/mysqltest | 01:21 |
| mtaylor | bzr push -r52 /tmp/mysqltest | 01:21 |
| mtaylor | (I was backwards in what I said earlier) | 01:21 |
| mtaylor | that produced: | 01:21 |
| mtaylor | bzr push into plugins tree (mtaylor:50 to 52) | 01:22 |
| mtaylor | of course, what I was really pushing was 51 to 52 | 01:22 |
| mtaylor | and in the log, I get 50 as well | 01:22 |
| mtaylor | doing log.show_log(self.branch, lf, verbose=True,direction='reverse',start_revision=self.old_revno,end_revision=self.new_revno) | 01:23 |
| lifeless | so | 01:23 |
| lifeless | sounds like something somewhere is not treating the interval as half_open correctly | 01:24 |
| mtaylor | what I did to try to work around it was: | 01:25 |
| mtaylor | new_graph = self.branch.repository.get_revision_graph(self.new_revid) | 01:25 |
| mtaylor | start_rev = get_parent(self.old_revid,self.new_revid,new_graph) | 01:25 |
| mtaylor | where get_parent was a recursive thing kept trying to walk the tree | 01:26 |
| mtaylor | but it seems really wrong (and the function breaks on some merges) | 01:27 |
| lifeless | mtaylor: just add one | 01:28 |
| lifeless | mtaylor: the docstring says clearly that its not a half open interval | 01:28 |
| === thumper_laptop is now known as thumper | ||
| mtaylor | wow. really? | 01:29 |
| * mtaylor punches himself in the face | 01:29 | |
| lifeless | pydoc bzrlib.log.show_log | 01:29 |
| lifeless | start_revision | 01:29 |
| lifeless | If not None, only show revisions >= start_revision | 01:29 |
| lifeless | end_revision | 01:29 |
| lifeless | If not None, only show revisions <= end_revision | 01:29 |
| mtaylor | lifeless: ok. I honestly don't know what crack I was originally smoking. | 01:39 |
| mtaylor | lifeless: but just adding 1 rather than trying to walk the tree sure does work perfectly | 01:39 |
| mtaylor | lifeless: so, have you seen the code that's in bzr-build for adding config info to the branch in a .bzr-builddeb/default.conf file? | 01:40 |
| mtaylor | bzr-builddeb I mean | 01:41 |
| poolie | hello mtaylor | 01:42 |
| mtaylor | hi poolie | 01:42 |
| poolie | lifeless: thanks for the RT request, i bumped it to joey | 01:42 |
| lifeless | mtaylor: I haven't looked at it, no. | 01:51 |
| AfC | A two week release cycle? | 02:03 |
| lifeless | no, 1.4 was late | 02:05 |
| AfC | {shrug} | 02:05 |
| AfC | so, that doesn't change the fact that it only just come out. | 02:05 |
| AfC | came* | 02:06 |
| * igc lunch | 02:08 | |
| AfC | I wouldn't dream of quibbling with "a good amount of code has landed" but you are jerking the chain of the people who do packaging | 02:08 |
| poolie | AfC: so the closest way to keep a precise cycle would be to do the rc1 now and have a longer lag til the release | 02:12 |
| poolie | is this an undue burden on packagers? | 02:12 |
| Odd_Bloke | AfC: I think jerking the chain of packagers is preferable to jerking the chain of users in general. Especially as a lot of bzr packagers are within the community (or are poolie), so are aware of what's going on. | 02:16 |
| AfC | Odd_Bloke: true | 02:34 |
| AfC | Odd_Bloke: and I should also concede that at the scale of third digit minor releases (in the sense of era.major.minor even though everyone insists on calling it major.minor.whatever) people are pretty used to doing bumps with no big deal | 02:36 |
| AfC | poolie, Odd_Bloke: but I have noted an enormous amount of dismay expressed by people that people writing plugins (and thence packages for those plugins) across the Bazaar space as a whole have seemed to have a hard time staying abreast. | 02:37 |
| fullermd | I don't feel jerked by the fairly fast release cycle. I feel a little flailing-in-the-dark on delayed releases, though. | 02:37 |
| AfC | Perhaps it would be less evident if the coupling between (say) {bzr-svn, bzr-gtk} and bzr was looser. | 02:38 |
| jelmer | AfC: bzr-gtk isn't coupled with particular bzr releases | 02:38 |
| AfC | jelmer: I'm glad to hear that | 02:39 |
| AfC | jelmer: though I must say that I seem to have a fairly strong recollection of frequently battling "this version imcompatible with installed bzr" warnings|errors in the not too distant past | 02:39 |
| jelmer | AfC, That was < 1.0 | 02:40 |
| AfC | Ah | 02:40 |
| jelmer | bzr-svn still has version warnings in place and so does bzrtools | 02:40 |
| === thumper_laptop is now known as thumper | ||
| lifeless | spiv: have you any immediate thoughts on: | 03:15 |
| lifeless | ERROR: test_add_lines_return (bzrlib.tests.test_versionedfile.TestVersionedFiles) | 03:15 |
| lifeless | vvvv[log from bzrlib.tests.test_versionedfile.TestVersionedFiles.test_add_lines_return(named-knit)] | 03:15 |
| lifeless | bzr: ERROR: [Errno 2] No such file or directory: '/tmp/testbzrrIvkG0.log' | 03:15 |
| spiv | lifeless: huh | 03:16 |
| spiv | lifeless: just "that shouldn't happen", | 03:16 |
| spiv | :) | 03:16 |
| lifeless | I have two things of concern here | 03:17 |
| spiv | lifeless: well, that and I would suspect the __dict__ clearing code that bit you yesterday might again be the culprit | 03:17 |
| lifeless | one is is: "test_add_lines_return (bzrlib.tests.test_versionedfile.TestVersionedFiles)" | 03:17 |
| lifeless | that id is the pyunit stock one, and wrong | 03:17 |
| lifeless | the other is the mithing log | 03:17 |
| spiv | Which is pretty worrying if true, it's meant to make testing faster and easier, not harder! | 03:18 |
| spiv | Ideally, we'd only clear tests that fail (hmm, which might be part of the reason I put it in run, you can't figure that out from tearDown/cleanup that I know of) | 03:19 |
| lifeless | well | 03:21 |
| lifeless | I think the problem here is in the approach | 03:21 |
| lifeless | reporting is done from objects to a stream | 03:22 |
| lifeless | the size issue you were trying to address is due to keeping objects around | 03:22 |
| lifeless | rather than cleaning up tests I suggest simply reporting to a stream at the time of failure | 03:22 |
| lifeless | then delete the entire test object | 03:22 |
| spiv | Right, but keeping the test cases around is potentially useful. | 03:22 |
| spiv | e.g. with a graphical runner. | 03:22 |
| lifeless | a graphical runner has different needs | 03:23 |
| spiv | I don't want to fight for hypothetical cases very hard, of course. | 03:23 |
| lifeless | well I'm just aying that the graphical runner can set a flag/fail to set a flag that controls this | 03:24 |
| lifeless | and in fact doesn't need to do either | 03:24 |
| lifeless | its conceptually simple: | 03:24 |
| lifeless | addError reports immediate | 03:24 |
| lifeless | thats in the Result object, which the runner provides | 03:24 |
| lifeless | the suite object deletes tests after running them | 03:24 |
| lifeless | so rather than for test in tests: run() | 03:24 |
| lifeless | its run(); del | 03:24 |
| spiv | Twisted has a suite that does that, IIRC. | 03:25 |
| lifeless | a graphical test runner that wants to keep the objects just has addError keep a reference to the test object | 03:25 |
| spiv | I suppose an alternative spelling more like what I tried is "test.run(); test.cleanThyself()" | 03:25 |
| lifeless | indeed; thats what I'm saying doesn't fit that well | 03:26 |
| spiv | (with smarts to only call cleanThyself on test objects that have that method, and only call it if the test passed...) | 03:26 |
| lifeless | it makes the object interface more complex, because now you need a 'clean' concept added, rather than just 'you are not needed anymore' | 03:26 |
| spiv | I guess I'm a bit reluctant to rely on the gc here. | 03:26 |
| lifeless | One useful way to think about this | 03:27 |
| jamesh | the twisted stuff also wants to do evil things like run a test multiple times | 03:27 |
| lifeless | is to consider subunit | 03:27 |
| spiv | jamesh: evil, but useful | 03:27 |
| lifeless | you can instantiate the test twice to do that | 03:27 |
| lifeless | thats simpler | 03:27 |
| jamesh | spiv: a reload() type interface would be better for that | 03:27 |
| spiv | jamesh: I've certainly wished for that feature in other runners when trying to debug intermittently failing tests | 03:27 |
| lifeless | spiv: so imagine all tests run under subunit - report *everything relevant* at failure time, and the object goes away. | 03:27 |
| spiv | I don't have any disagreement with instantiating a test twice to run it twice. | 03:28 |
| lifeless | spiv: I really think this would be simpler and less prone to errors/race conditions | 03:28 |
| spiv | The only reason I see for keeping a test object around after running it is for debugging and reporting (and the reporting really ought to be all done by the time run() returns) | 03:28 |
| jamesh | lifeless: I know you're busy, but if you have a chance to look at my bzr-dbus patches at some point it'd be appreciated | 03:28 |
| spiv | But it's relatively easy to accidentally hang on to objects, so rather than hoping that "del test" is releasing the last reference to the test case in the face of complicated test suite infrastructure, I thought that just resetting the test case object's state to the minimum possible would be more reliable. | 03:29 |
| spiv | Twisted has certainly found that trying to release all references is hard to do. | 03:30 |
| jamesh | weak references can help catch that sort of bug | 03:30 |
| spiv | So, I'm completely happy to remove the reference, but it just seems prone to not actually having any effect unless we're always very careful. | 03:31 |
| lifeless | jam: still around ? | 03:31 |
| lifeless | spiv: so, can we tell how many references an object has ? | 03:32 |
| spiv | sys.getrefcount in CPython | 03:32 |
| lifeless | spiv: so we can write tests that the test framework is wellbehaved | 03:32 |
| spiv | Although it's easy to get confused because you need a reference to it to ask how many references there are :) | 03:32 |
| lifeless | for addCleanup etc | 03:32 |
| lifeless | and if an individual test happens to leak; so beit - its much better than leaking 11111 tests | 03:33 |
| lifeless | anyhow, late lunch for me | 03:34 |
| jamesh | lifeless: it'd be clearer to do something like: ref = weakref.ref(test); del test; assert ref() is None | 03:38 |
| jamesh | if you want to check for leaks | 03:38 |
| * spiv wonders why lifeless is noticing bugs here all of a sudden | 03:40 | |
| * spiv -> food | 03:40 | |
| lifeless | spiv: well, the id() one had been annoying me for a bit, but I generally had only one variant failing, when I had 6 it become important | 04:03 |
| lifeless | jamesh: re testing, yes, thats how to tell if its leaked; but you need to run the test framework in the middle there | 04:04 |
| poolie | lifeless, a word in your shell-like ear? | 05:38 |
| poolie | spiv and i are working on finishing the smart protocol changes | 05:39 |
| poolie | if the server is too old to understand the new request, we'll drop the connection and restart | 05:39 |
| poolie | unfortunately the previous logic for understanding the response to the 'hello' rpc is wrong; the client is upset if the server says it's newer | 05:40 |
| poolie | as i recall you thought this was a good move when we had another similar situation | 05:40 |
| poolie | so it looks like we will stop sending the explicit 'hello' from new clients, and instead just see what the server says about the first command | 05:43 |
| * igc pick up kids - bbiab | 05:43 | |
| poolie | bye | 05:44 |
| lifeless | poolie: uhm, I've never liked hello. If you are proposing to stop using hello's then great. | 06:06 |
| lifeless | poolie: otherwise I think I don't understand your word | 06:06 |
| poolie | so, basically: just send a call in the latest version | 06:07 |
| poolie | if the server doesn't understand it, disconnect and try again | 06:07 |
| poolie | i think the only contentious part of this is: is it ok to drop the connection and restart if the server doesn't understand? | 06:08 |
| poolie | it's undesirable but avoiding it seems complex | 06:08 |
| poolie | so i think it's acceptable | 06:08 |
| poolie | hopefully this will be the last such transition | 06:08 |
| lifeless | we already have the compromise of dropping the connection | 06:09 |
| lifeless | so I think its fine | 06:09 |
| poolie | right | 06:09 |
| poolie | me too | 06:09 |
| lifeless | I think it would be nice | 06:10 |
| lifeless | if we could figure out the ssh magic to drop the ssh channel but keep the ssh session | 06:10 |
| poolie | full stop? | 06:10 |
| poolie | yes, spiv said that too | 06:10 |
| lifeless | greats minds | 06:10 |
| poolie | mm | 06:11 |
| poolie | given all the different ssh situations i think that may be hard | 06:11 |
| lifeless | without more ssh protocol knowledge I have no idea | 06:12 |
| poolie | if we really want to avoid dropping it i think we'd do better to start by sending a command in an old encoding which old servers will understand, but give an error without losing the connection | 06:12 |
| poolie | well, we use putty, paramiko, openssh and ssh.com ssh | 06:12 |
| poolie | and i think there is no standard way to get it... | 06:12 |
| poolie | it would probably be good to have some documentation about "hey you should turn this feature on" as it's generally useful | 06:13 |
| lifeless | poolie: I'm not talking about master session stuff | 06:20 |
| poolie | i know, but it's similar, is it not? | 06:22 |
| lifeless | I think the underlying mechanism is reused | 06:25 |
| lifeless | yay, add_lines -nearly- done | 06:29 |
| lifeless | deep depdency:) | 06:29 |
| lifeless | well, I'm past 8 hours now, so gnight! | 06:30 |
| === vigneswaris is now known as vigneswari | ||
| === indraveni is now known as ksp | ||
| === ksp is now known as indraveni | ||
| * igc dinner | 08:28 | |
| spiv | poolie: Hmm, I've hit a surprise bug, so I won't get this patch to the list until tomorrow morning. | 08:39 |
| spiv | (it turns out I was forgetting to send the protocol version marker string on v3 responses!) | 08:40 |
| === mark1 is now known as markh | ||
| Winterstream | I realize that this channel isn't exactly aimed at bzr-svn, but hopefully someone can help me. The problem is that bzr-svn changes SVN properties every time I do check-ins. SourceForge reports these changes and they seem to get longer every time. I don't ever do merging (I always rebase), so it seems as if bzr-svn doesn't really need the info it stores in the properties. Any idea whether bzr-svn can work without the property changes? | 12:00 |
| james_w | Winterstream: I don't know if bzr-svn could possibly work without them, but I don't think there is currently a way to turn it off at least. | 12:10 |
| === cprov is now known as cprov-lunch | ||
| === mrevell is now known as mrevell-lunch | ||
| jelmer | Winterstream: there's no way to do that at the moment, but please file a bug and I'll have a look at implementing it for the next release | 12:27 |
| jelmer | Winterstream: Not setting the properties will have to consequence that you can no longer pull from svn into the branch you pushed to | 12:28 |
| === mrevell-lunch is now known as mrevell | ||
| gabees | hello all, running Gutsy server, added the intrepid main to my sources, ran update, checked bzr and it is still showing the old version. Is any one able to give me some help with this please? | 12:47 |
| RAOF | gabees: By 'update' you mean 'apt-get update' or 'apt-get upgrade', or both? (1) You need both - update then upgrade (or dist-upgrade), and (2) I hope that gutsy server doesn't need to work. | 13:00 |
| RAOF | gabees: Intrepid will break, and break hard, many times over the next month. | 13:02 |
| Winterstream | jelmer - I figured as much. Thanks :) | 13:04 |
| gabees | no look, I followed the instructions on the bzr site for upgrading it: https://launchpad.net/~bzr/+archive | 13:09 |
| gabees | it says to added these intrepid repo | 13:09 |
| gabees | but the repo only contains bzr and bzr-tools | 13:09 |
| gabees | I did update, and then upgrade | 13:09 |
| gabees | but it won't recognise the new version in the intrepid repo | 13:09 |
| gabees | hehe | 13:09 |
| gabees | i'm now trying to upgrade the entire server to hardy | 13:10 |
| gabees | that include 1.3 | 13:10 |
| _paneb | is a repository usually created for each project? | 13:16 |
| _paneb | or is there one repository for all projects (and their branches)? | 13:16 |
| gabees | _paneb: one repo for all | 13:29 |
| fullermd | Depends on who created it and what they wanted to do. | 13:30 |
| _paneb | i will be creating it, and i just want to control several projects | 13:31 |
| fullermd | I tend to not mix projects in one repo. | 13:31 |
| _paneb | when working "solo" do i create my repositories with trees? | 13:34 |
| _paneb | nevermind, i understand now what --no-trees is for | 13:41 |
| fullermd | Well, again, it depends on what you need. tree/no-trees is just a default; you can always create a tree on a branch without one, and remove a tree from a branch with one. | 13:42 |
| _paneb | right | 13:43 |
| fullermd | Some things I tend to create branches only to use right off, so they tend to be trees. Others a lot of branches sit around a while, so they're no-trees. | 13:43 |
| fullermd | And then there are the work styles where you use lightweight checkouts somewhere other than the repo, in which case you want no-trees. | 13:43 |
| igc | night all | 13:53 |
| gabees | upgraded to hardy heron now | 14:02 |
| gabees | that's got a newer version of bzr | 14:03 |
| === mw|out is now known as mw | ||
| === hmeland_ is now known as hmeland | ||
| fbond | lifeless: I'll be adding to that quilt/loom wiki page further when I can. | 14:21 |
| fbond | lifeless: It must be emphasized more strongly that carrying live changes in the working tree across threads (up-thread, down-thread, etc.) can be rather terrible. | 14:22 |
| === mw is now known as mw|brb | ||
| fbond | lifeless: If conflicts occur, you are left in the unpleasant situation of having to extricate your valuable changes from a variety of potentially conflicting files. | 14:23 |
| fbond | I guess if your instinct is correct (restore from backups), things can go okay. | 14:23 |
| fbond | But my instinct in the past has been to quickly move back to the thread that I came from. | 14:23 |
| fbond | Which creates more conflicts. :) | 14:24 |
| fbond | Perhaps it would be good to refuse to switch threads when live changes are present? | 14:24 |
| fbond | (Or at least if arriving at destination thread will result in merges or conflicts) | 14:25 |
| fbond | s/merges/new merges requiring commits/ | 14:25 |
| bob2 | live = uncommited? | 14:26 |
| fbond | bob2: yep | 14:27 |
| jam | fbond: it is a design goal to allow you to switch with uncommitted changes | 14:28 |
| krow | statik: ? | 14:28 |
| jam | so you can make a change that should be on a different thread | 14:29 |
| jam | realize it | 14:29 |
| jam | switch threads | 14:29 |
| jam | and then commit | 14:29 |
| fbond | jam: I'd like to believe that :) | 14:29 |
| jam | fbond: conflicts are probably different | 14:29 |
| fbond | jam: But the reality of the situation is that the user experience is a bit jarring. | 14:29 |
| jam | lifeless: I'll need you to create the bzr-1.5 branch when you get some pqm time. i'll try sending an email in case you miss this | 14:30 |
| fbond | jam: Both of those situations are an immediate headache (new merges, conflicts) | 14:30 |
| fbond | The only good way I know to deal with it is `bzr shelve', `bzr switch', [resolve,commit,etc], `bzr unshelve', [carry on with life] | 14:30 |
| fbond | But that requires some pretty good foresight. | 14:31 |
| jam | fbond: I don't have much personal experience with the loom plugin, I just follow along :) | 14:32 |
| jam | fbond: so what is causing the conflicts that you are trying to roll back to the earlier thread | 14:33 |
| jam | I'm just trying to follow a little bit closer so I might give suggestions | 14:33 |
| fbond | jam: I hope this is not too harsh: loom is to what it should be as git's UI is to bzr's. | 14:33 |
| fbond | jam: There are a few different ways conflicts can happen. | 14:33 |
| fbond | Each thread switch is an implicit merge. | 14:34 |
| fbond | If I do: | 14:34 |
| fbond | bzr commit ... | 14:34 |
| fbond | bzr up-thread | 14:34 |
| fbond | I get a new merge that now needs to be committed. | 14:34 |
| fbond | (in the higher thread) | 14:34 |
| fbond | This merge can conflict. | 14:34 |
| fbond | Further, I can also have working tree conflicts. | 14:34 |
| jam | How is "this merge can conflict" separate from "working tree conflicts" | 14:35 |
| fbond | The merge can conflict with the branch. | 14:35 |
| jam | I guess I'm not understanding how the merge can conflict | 14:35 |
| fbond | So you get branch-branch conflicts as well as working tree-branch conflicts. | 14:35 |
| fbond | Threads are nearly branches. | 14:36 |
| fbond | I guess in the end the conflicts are all sitting in your WT, but they originate differently. | 14:36 |
| jam | fbond: ok, so the files on disk get conflicted, but if you have live (uncommitted) changes they can also conflict | 14:36 |
| jam | fbond: I was just confused by your terms | 14:36 |
| fbond | jam: Sorry, I don't know bzr's internal concepts as well as you do. | 14:36 |
| fbond | So I probably use bad language. | 14:36 |
| jam | I wouldn't claim that | 14:37 |
| fbond | jam: I would :) | 14:37 |
| jam | fbond: so the issue is that switching trees might conflict | 14:38 |
| fbond | Anyway, the end result is that switching threads can't be done as casually as you'd like. | 14:38 |
| jam | and then after that you have an implicit merge | 14:38 |
| jam | which might conflict *on top* of that | 14:38 |
| fbond | Right, conflicts aren't the only issue, though. | 14:38 |
| fbond | If I have uncommitted changes in the WT and I switch to a higher thread, causing an implicit merge (with no conflicts) my WT now contains my new changes, but it also contains a merge that needs to be committed. | 14:39 |
| fbond | So I have to extricate the changes that I was carrying around in the WT from the merge itself. | 14:39 |
| jam | fbond: sure, I think the "switch with uncommitted changes" is meant more for down-thread, not up-thread | 14:39 |
| fbond | jam: Okay, possible. | 14:39 |
| jam | and I see your point about difficulties | 14:39 |
| jam | so.... what would be my resolution | 14:40 |
| fbond | jam: Yeah, I like using loom, but when I forget to shelve before these critical thread switches, it's pretty frustrating. | 14:40 |
| jam | fbond: would it be easier if up-thread refused with uncommitted changes | 14:40 |
| jam | or if you could at least set a flag for that | 14:40 |
| jam | or require --force, etc | 14:40 |
| fbond | jam: Right. You could be a little more granular and say "up-thread refuses if the switch would result in uncommitted merges and/or working tree conflicts" | 14:41 |
| jam | it would, unfortunately, make up-thread a bit slower, as it would have to check for changes before moving | 14:41 |
| fbond | But that might not be as predictable. | 14:41 |
| jam | fbond: doesn't up-thread always result in an uncommitted merge | 14:41 |
| krow | Hi! I just had bzr puke on commit on me: | 14:41 |
| krow | http://pastie.caboo.se/192356 | 14:41 |
| jam | I thought that was part of the design | 14:41 |
| fbond | jam: Nope. | 14:41 |
| jam | well, I suppose it might already be merged | 14:41 |
| fbond | Exactly. | 14:41 |
| fbond | (And that is more often than not) | 14:41 |
| jam | krow: have you been doing something interesting with the "plugin/daemon_example" directory? | 14:42 |
| jam | It is at least claiming that you have a file inside it, but the actual directory is not present | 14:42 |
| jam | krow: any chance you could paste "bzr log -r -10..-1 --short --verbose" ? | 14:44 |
| jam | krow: this is bug #150438, btw | 14:45 |
| ubottu | Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed] https://launchpad.net/bugs/150438 | 14:45 |
| krow | jam: Yeah... I did an rm without a bzr | 14:47 |
| jam | hmm... sounds like an auto-detect error | 14:47 |
| jam | we detect that the directory is removed | 14:47 |
| jam | but don't propagate that to all the children properly. | 14:48 |
| jam | krow: is this during "bzr commit "? | 14:48 |
| krow | jam: Yes | 14:48 |
| jam | krow: so you did something like | 14:49 |
| jam | rm -rf plugin/daemon_example | 14:49 |
| jam | bzr commit -m 'xxxx' | 14:49 |
| jam | and it blows up like this? | 14:49 |
| jam | or you did that a while ago | 14:49 |
| jam | and now it is complaining | 14:49 |
| krow | jam: Dd the rm and then did the commit | 14:49 |
| krow | jam: Currently stuck at the commit... :* | 14:50 |
| krow | jam: Currently stuck at the commit... :( | 14:50 |
| krow | jam: http://pastie.caboo.se/192357 That is from the command you asked me to run | 14:50 |
| jam | krow: you've been doing a lot of housekeeping :) | 14:50 |
| krow | jam: Yes :) | 14:51 |
| krow | jam: So thoughts on how to get out of this? | 14:51 |
| jam | krow: well, there are certainly ways to reset things | 14:51 |
| jam | I'm not sure what is best righ tnow | 14:52 |
| jam | is the only change removing some directories | 14:52 |
| jam | (aka easily redone) | 14:52 |
| jam | or is there more complex stuff | 14:52 |
| jam | krow: for example, you could do | 14:52 |
| jam | cd .. | 14:52 |
| jam | bzr checkout --lightweight plugin alt_plugin | 14:53 |
| jam | rm plugin/.bzr/checkout | 14:53 |
| jam | mv alt_plugin/.bzr/checkout plugin/checkout | 14:53 |
| jam | krow: don't do it until we've sorted things out, though | 14:53 |
| jam | that will reset bazaar into thinking you haven't done anything to your tree | 14:53 |
| jam | So simple changes like removing directories should be fine | 14:53 |
| krow | jam: Ok... | 14:53 |
| jam | as should modified files, etc | 14:54 |
| jam | renames will be lost | 14:54 |
| jam | but you can use "bzr move --after" | 14:54 |
| jam | krow: I would *really* like to understand how it got into this situation, thoguh | 14:54 |
| krow | jam: All there is, is modified files and rm'ed stuff. No moving. | 14:55 |
| krow | jam: I can save a copy of the tree. | 14:55 |
| jam | krow: if you could, that would be nice | 14:55 |
| jam | my concern is that it was the steps leading up to this that caused the problem | 14:55 |
| jam | and a post-mortem isn't going to reveal the secrets | 14:55 |
| jam | but it is better than nothing | 14:55 |
| === mw|brb is now known as mw | ||
| jam | fbond: it is pretty easy to detect if we would need to merge, would that UI suit you? | 14:56 |
| jam | fbond: just to finish the conversation :) | 14:56 |
| jsled | I'm trying to make sure I understand something about bzr history and merging. In a situation with multiple developers having a centralized/remote shared repo (bzr+ssh access) and each having local shared repos with a branch from the remote trunk … is <http://paste.lisp.org/display/60340> accurate? | 14:59 |
| jsled | I might be wrong on the version numbering in the merge commit. It probably makes more sense if the two developers both branch from (and "share") commit 1. | 15:00 |
| beuno | jsled, looks exactly like what I'm using :) | 15:00 |
| krow | jam: Well, this thing is 596M tarred/compressed | 15:00 |
| krow | jam: Is there a way to permanently snip history? | 15:00 |
| beuno | jsled, is there a specific concern for this workflow, or are you just making sure? | 15:01 |
| jam | krow: well, you could rm .bzr/repository/packs/... | 15:01 |
| jam | I'm mostly interested in the WT | 15:01 |
| jam | also, a 'make clean' or equivalent is usually good | 15:01 |
| jsled | beuno: | 15:01 |
| krow | jam: Problem: | 15:01 |
| jam | so I'm not getting .o files | 15:01 |
| krow | [brian@localhost plugin]$ bzr checkout --lightweight plugin alt_plugin | 15:01 |
| krow | bzr: ERROR: Not a branch: "/home/brian/Other/mysql-6.0-brian/plugin/plugin/". | 15:01 |
| jsled | er. beuno: It's wicked confusing, as the revision numbers keep jumping around. | 15:02 |
| jam | krow: did you miss the "cd .." ? | 15:02 |
| jsled | As well, trying to use the revision number as a build number becomes impossible. | 15:02 |
| jsled | It makes the history really hard to search for changes. | 15:02 |
| jam | jsled: there is a recommended workflow which gets around that | 15:02 |
| fbond | jam: Yes, I'd be happier with the UI if it didn't help me shoot myself in the foot. | 15:02 |
| krow | jam: Is the command from the root of the repository, or from outside of it? | 15:03 |
| jam | and a flag you can set so that the second 'bzr push' won't let the mainline revno jump around | 15:03 |
| jam | krow: you have "$repo/plugin" right? | 15:03 |
| jam | where "plugin" is the branch? | 15:03 |
| jam | so you want to be above the branch | 15:03 |
| jsled | jam: I've love to hear/read about it. I've thought baout trying to encourage the use of "rebase", but the workflow is already pretty complicated. | 15:03 |
| jam | so that you can do "bzr co --lightweight a_branch other_branch" | 15:03 |
| jam | jsled: so, #1 is to use a checkout for your mainline, which people then merge into and "bzr commit" to update the tip | 15:04 |
| jam | let me check #2 real quick | 15:04 |
| jam | #2 "echo 'append_revisions_only = True' >> .bzr/branch/branch.conf | 15:04 |
| vigneswari | hello all... | 15:04 |
| beuno | jsled, rebase is stronly disencouraged as it breaks history, and leaves branches unmergeable | 15:05 |
| vigneswari | we have one distro based on debian | 15:05 |
| beuno | jam, do you know what adding appen_revisions_only does? | 15:05 |
| vigneswari | planned to maintain source using bzr | 15:05 |
| jam | beuno: if it would change your mainline revisions it refuses the push | 15:05 |
| krow | jam: http://pastie.caboo.se/192366 | 15:05 |
| beuno | jam, does it force #1 or similar, or just create new revs instead of subrevs? | 15:06 |
| vigneswari | currently we have the bzr repo in local machine and our team is using locally using ssh authentication | 15:06 |
| beuno | jam, ah, that's what I thought, thanks :) | 15:06 |
| jsled | beuno: breaks history? To be clear, by "rebase" I mean the process of moving a sequence of commits to the tip after each pull … basically so there are no merge commits. | 15:06 |
| vigneswari | but i dont know how to make it public | 15:06 |
| jam | krow: interesting.... I think I know why, but trying to figure it out for a second | 15:06 |
| vigneswari | bzr+ssh is better or ftp? | 15:07 |
| jam | krow: I believe what is happening is that "bzr checkout" is trying to copy files from your source checkout, and failing | 15:07 |
| vigneswari | want to know hoe to configure this | 15:07 |
| jam | krow: so we need to tell it that there isn't actually a checkout there | 15:07 |
| jam | krow: so do "mv mysql-6.0-brian/.bzr/checkout mysql-6.0-brian/.bzr/checkout-old" | 15:07 |
| vigneswari | plz someone help me to do this | 15:07 |
| jam | krow: and then try the same "checkout --lightweight" | 15:07 |
| vigneswari | any suggestions? | 15:07 |
| jam | krow: and then you should be able to mv 'alt/.bzr/checkout mysql-6.0-brian/.bzr/checkout' | 15:08 |
| beuno | jsled, yes, I understand. But rebase removes many references, so it makes it impossible to use continuosly | 15:09 |
| bob2 | vigneswari: you can make it publically available just by letting anonymous users have read only access via ftp or http | 15:09 |
| beuno | vigneswari, bzr+ssh is much faster as it uses the bzr smart server | 15:09 |
| beuno | vigneswari, if you want to make it public, http is probably the best way to go | 15:09 |
| bob2 | really? at least bzr:// was slower for some operations. | 15:10 |
| vigneswari | bob2, beuno , readonly? if they want to edit the source and to contribute.. | 15:10 |
| beuno | vigneswari, well, bzr+ssh is fine then | 15:10 |
| bob2 | vigneswari: then give them ssh access so they can use bzr+ssh or sftp | 15:10 |
| jsled | beuno: Just curious, what sort of references? Or does it get into bzr internals? I mean, abstractly, one could create a diff for each commit, uncommit+revert them, pull, then re-apply the merges + commits in sequence. I'm not sure what references would be lost. | 15:11 |
| vigneswari | bob2, any doc for using sftp? | 15:11 |
| beuno | bob2, well, there are some things to fix with the smart server so it's faster in every operation. But i think in general, it's faster | 15:11 |
| bob2 | vigneswari: same way they would use sftp for anything else - it doesn't require any special bzr-specific configuration | 15:11 |
| jam | fbond: bug #227339 | 15:12 |
| ubottu | Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339 | 15:12 |
| fbond | jam: thanks | 15:12 |
| beuno | jsled, I really don't know many specifics. I believe mainly what was merged from where, thus, making it impossible for people merging in changes done in different points of the timeline | 15:12 |
| vigneswari | bob2, is it adviceable to give write permission to others... | 15:13 |
| jsled | fbond: hey. :) | 15:13 |
| jam | beuno, bob2: bzr+ssh is generally much faster than sftp, atm it is on par with http, but getting better | 15:13 |
| fbond | jsled: Hi :) | 15:13 |
| bob2 | vigneswari: sorry, I don't understand the question... | 15:13 |
| fullermd | It's much slower than http for write operations. Writes over http get done real quick :p | 15:13 |
| beuno | jam, I recall a few discussions during the sprint where the smart server was slower than http, was that solved? I know it's always faster than sftp | 15:13 |
| jam | jsled: the big difference with "rebase" is that you don't actually record that you merged the other person's changes | 15:13 |
| beuno | fullermd, lol | 15:14 |
| bob2 | hey I think the http cgi write thing does work nowadays | 15:14 |
| jam | beuno: I don't believe it has all been solved | 15:14 |
| jam | it is something spiv is working on | 15:14 |
| jsled | jam: those numbered points from earlier … are they from a particular list (a FAQ that I should have searched for first, maybe? :) | 15:14 |
| vigneswari | bob2, that means ssh authentication to whoever wants.. | 15:15 |
| jam | jsled: I don't think "append_revisions_only" is well documented, it only seems to be exposed via "bzr init" | 15:15 |
| fbond | jsled: In bzr, revisions are a tree snapshot (although they may not be stored as such) and a parent revision. Rebase rewrites history, thus destroying historical correlation with branches whose parent revision is in the rebased branch. (Somebody correct me if I'm wrong) | 15:15 |
| jam | jsled: the workflow is: http://bazaar-vcs.org/Workflows?highlight=%28workflow%29#head-ca3ccf73574776b36453b2213789731549e54167 | 15:15 |
| jam | But that doc doesn't get into enough detail about *why* you would want that way | 15:15 |
| krow | jam: Thanks! I believe that got me working again. | 15:15 |
| bob2 | vigneswari: don't give people ssh access unless you want them to be able to modify your bzr repository | 15:15 |
| jam | It just says it exists | 15:15 |
| bob2 | vigneswari: you can make it available, read-only, via ftp, http, bzr://, etc | 15:16 |
| beuno | vigneswari, you could use something like bundlebuggy if you want something intermediate | 15:16 |
| beuno | and work with patches | 15:16 |
| beuno | although it might be an overkill | 15:16 |
| vigneswari | bob2, thanks | 15:17 |
| jam | jsled: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#decentralized-with-shared-mainline | 15:17 |
| Lo-lan-do | Hi there | 15:17 |
| jam | is the same thing in a different document | 15:17 |
| jam | and is the more "canonical" location for that documentation | 15:17 |
| bob2 | boomtish | 15:17 |
| Lo-lan-do | Is there a simple way to know from a heavy checkout whether I'm missing some revisions from the master branch? | 15:18 |
| bob2 | bzr missing? | 15:18 |
| jam | krow: also, bzr 1.4 has been released, any chance you could upgrade to it? | 15:19 |
| Lo-lan-do | bob2: That will get me the revisions I'm missing from the parent branch, which is not necessarily the master branch. | 15:19 |
| bob2 | ah | 15:19 |
| jam | Lo-lan-do: well 'bzr missing http://path/to/maste/branch" will | 15:20 |
| jsled | jam: Is it me, but is there a `bzr push` missing from that workflow, though? I mean, a) that's very similar to the workflow we have, and b) I don't see how one can issue a commit to a remote branch. | 15:20 |
| jam | but certainly is a bit to type | 15:20 |
| jam | jsled: the checkout | 15:20 |
| Lo-lan-do | jam: Yeah, hence my request for a "simple" way :-) | 15:20 |
| jam | does the push for you | 15:20 |
| jsled | jam: What checkout? | 15:20 |
| krow | jam: I tend to stick to whatever the distribution provides (though sometimes I will use the python (forget the name of it) tool to upgrade python bits) | 15:20 |
| jam | krow: you are probably thinking "easy_setup/easy_install" | 15:21 |
| jam | krow: what distribution are you on? Hardy or debian | 15:21 |
| Lo-lan-do | jam: Could there be a new revisionspec for that? Like "bzr missing -rmaster:"? | 15:21 |
| jam | (since you have 1.3.1) | 15:21 |
| krow | jam: FC :) | 15:21 |
| jam | Lo-lan-do: I suppose it could, if 'missing' took a revision id | 15:21 |
| Lo-lan-do | Ah, yeah, I'm confused. | 15:22 |
| jam | krow: hm.... I wonder why they have an rc1 as their official version | 15:22 |
| krow | jam: Who knows... RH has shipped alphas as well. | 15:22 |
| Lo-lan-do | Maybe a "bzr update --mising" then? | 15:22 |
| jam | Lo-lan-do: well, 'bzr status' could also check if this is a bound branch and if the remote tip == this tip | 15:23 |
| jam | it already does it for normal checkouts | 15:23 |
| Lo-lan-do | or --show-missing, or something | 15:23 |
| jam | jsled: let me put up a patch to the document, which might help you understand a bit more | 15:23 |
| jam | jsled: I might as well get it written down | 15:23 |
| fbond | jam: #227339 doesn't cover the case where there are no new pending merges, but there are plain WT conflicts. | 15:23 |
| fbond | Shall I create a new bug to cover that case? | 15:24 |
| jam | bug #227339 | 15:24 |
| ubottu | Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339 | 15:24 |
| fbond | Or piggy back on that one? | 15:24 |
| jsled | jam: That'd be awesome. I just don't see a "bzr checkout" in that section, is all. :/ | 15:24 |
| jam | fbond: feel free to post that as well | 15:24 |
| jam | they *might* be different issues | 15:24 |
| jam | conflicts would be considered an uncommitted change | 15:25 |
| fbond | jam: They are obviously related, but are different cases (although they can overlap). | 15:25 |
| fbond | jam: I'll create a new bug. | 15:25 |
| jam | fbond: you can always say "see also bug #227339" in your comment, so people can easily jump between them | 15:25 |
| ubottu | Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339 | 15:25 |
| jam | jsled: does this clarify it a bit: http://pastie.caboo.se/192384 | 15:29 |
| jsled | jam: it does, for the example. | 15:32 |
| fbond | jam: bug #227339 | 15:35 |
| ubottu | Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339 | 15:35 |
| fbond | jam: eh, I mean bug #227349 | 15:35 |
| ubottu | Launchpad bug 227349 in bzr-loom "Should refuse to switch threads if doing so would cause a WT conflict" [Undecided,New] https://launchpad.net/bugs/227349 | 15:36 |
| jam | fbond: I'm not sure that refusing to switch because of a conflict is the correct solution | 15:37 |
| jam | because you will always get conflicts when people change similar parts of code | 15:37 |
| fbond | jam: I guess I make a distinction between what I call "branch conflicts" and "working tree conflicts" | 15:38 |
| jam | fbond: I'll clarify on the bug | 15:38 |
| fbond | jam: thanks | 15:38 |
| fbond | (to be clear: I say "WT conflict" when I mean "a conflict between an uncomitted change and the branch") | 15:39 |
| fbond | jam: BTW, I'm open to suggestions WRT wording :) | 15:39 |
| jam | fbond: wouldn't this be handled by bug #227339? | 15:40 |
| ubottu | Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339 | 15:40 |
| jam | fbond: because you can't switch if it is going to merge and you have uncommitted changse | 15:40 |
| jam | thus it can't conflict | 15:40 |
| fbond | jam: No, I'm not talking about a situation where there are uncommitted merges. | 15:41 |
| fbond | jam: Here's the scenario: | 15:41 |
| fbond | I'm in thread A | 15:41 |
| fbond | I make some changes to source files. | 15:41 |
| fbond | I switch to thread B. | 15:41 |
| fbond | My current WT can conflict with the previously committed state of thread B. | 15:41 |
| fbond | Thus, a WT conflict arises. | 15:41 |
| fbond | (And there are no pending merges) | 15:42 |
| jam | fbond: ok, I think I follow | 15:42 |
| _paneb | when working with the SVN-style repository layout (http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#choosing-a-shared-repository-layout), day-to-day work is performed on the feature branches, and then once a feature is ready to be commited, the feature-branch is merged with trunk? | 15:44 |
| jam | fbond: ok, check the updated text on bug #227339, let me know if it captures your ide | 15:46 |
| jam | idea | 15:46 |
| ubottu | Launchpad bug 227339 in bzr-loom "up-thread should refuse if it would co-mingle changes" [Undecided,New] https://launchpad.net/bugs/227339 | 15:46 |
| jam | For the example I was able to put together | 15:46 |
| jam | I have to say, you sort of have to handle that conflict in that situation | 15:47 |
| jam | so i'd like to have another example that would make it more obvious that you don't want to switch | 15:47 |
| jam | _paneb: the feature is merged *into* trunk | 15:47 |
| _paneb | ok | 15:47 |
| fbond | jam: Well, switching threads is typically done pretty casually. | 15:48 |
| jam | _paneb: generally you only merge trunk => feature_branch if there is something potentially conflicting, etc being done by trunk | 15:48 |
| _paneb | i used the wrong word :) | 15:48 |
| _paneb | i meant branch => trunk | 15:48 |
| fbond | jam: Sometimes, I pass through one thread on my way to another (I guess I could use bzr switch...) | 15:48 |
| jam | fbond: I think it still has to go through the intermediate threads | 15:48 |
| _paneb | and while the feature is not quite complete yet, it is only committed to the feature-branch, right? | 15:48 |
| jam | fbond: anyway, it would be nice to have a clearer example of why this is necessary | 15:48 |
| jam | _paneb: correct | 15:49 |
| jam | (for some values of incomplete) | 15:49 |
| _paneb | non-working | 15:49 |
| jam | _paneb: having worked on projects with distributed development, you still want to merge your changes in fairly often to avoid drift | 15:49 |
| jam | _paneb: but yes, while your branch is not at a point it can be used, you leave it in the feature branch | 15:50 |
| _paneb | right ok | 15:50 |
| jam | my point is more about project management | 15:50 |
| jam | having someone work for 2 years on their own branch before merging | 15:50 |
| jam | is not recommended :) | 15:50 |
| _paneb | heh indeed | 15:50 |
| fbond | jam: Hmm. Your example is correct, but you seem to be marginalizing the issue :) | 15:51 |
| jam | fbond: I felt the example was marginal, which is why I asked for a better example | 15:51 |
| fbond | jam: For me atleast, it is not uncommon to carry uncommitted changes around in my loom for a fair bit while I sort out which changes should be committed where. | 15:51 |
| fbond | jam: In other words, I occasionally go wild implementing features/fixes and then sort out after the fact where those should actually be committed. | 15:52 |
| jam | fbond: your organizational issues are up to you :) | 15:52 |
| jam | I don't use looms, and instead rely on 200+ feature branches | 15:52 |
| jam | so when I get an unrelated change | 15:52 |
| jam | it tends to be | 15:52 |
| jam | cd .. | 15:52 |
| fbond | jam: Well, sometimes I start out looking at one thing and find other things that should be tweaked. | 15:52 |
| jam | bzr branch feature_foo bugfix_bar | 15:52 |
| jam | cd bugfix_bar | 15:52 |
| fbond | jam: Yeah, I considered using many branches instead of loom. | 15:52 |
| jam | bzr merge --uncommitted ../feature_foo | 15:53 |
| fbond | jam: I guess this is why some people have pushed for faster git-style switch ... | 15:53 |
| fbond | jam: Anyway, so assume that I might end up collecting several different changes in my WT simultaenously and then look for places to commit them afterwards. | 15:54 |
| fbond | jam: Surely, you can see how I might carry a good size diff around the loom for a while, and in my frequent loom commands, every now and again I get an undesired WT conflict. | 15:54 |
| fbond | jam: That conflict could have been avoided in some circumstances. | 15:55 |
| fbond | jam: If loom says "won't merge as it would cause a WT conflict" | 15:55 |
| fbond | I'll skip over that thread and switch directly to the thread where I want to merge the conflicting change. | 15:55 |
| fbond | Then I only have to resolve necessary conflicts, and never have to resolve conflicts just to regain mobility on the loom. | 15:55 |
| fbond | jam: Is my expectation unreasonable? | 15:56 |
| jam | fbond: I think you are using "loom" as a replacement for git-style branches | 15:58 |
| jam | which it is *not* intended fro | 15:58 |
| jam | for | 15:58 |
| jam | it is meant as building up a series of patches | 15:58 |
| jam | I can't say we have a great answer for multiple non-related branches | 15:58 |
| jam | in the same WT | 15:58 |
| jam | I believe that was discussed at the last sprint | 15:58 |
| _paneb | and when i first start working on a new feature, i create the new branch and push it to the central location? | 15:59 |
| jam | _paneb: your choice as to whether you push it or not, depends on whether you want it visible to others | 15:59 |
| jam | while you are working on it | 16:00 |
| fbond | jam: Well, my intention is rarely to create a cluster-f****d working tree. Rather, I set out to create a sane series of patches, but sometimes I end up with scattered changes that need homes. | 16:00 |
| _paneb | jam, ok | 16:00 |
| jam | fbond: and I think that is reasonable, I think an answer is to make it easier to do that sort of thing as unrelated branches with switch, etc. | 16:00 |
| jam | I don't honestly know how switch works with looms | 16:01 |
| jam | my understanding is that it would have to 'up-thread/down-thread' between all of them | 16:01 |
| jam | but maybe it allows you to jump directly | 16:01 |
| fbond | jam: it does | 16:01 |
| fbond | jam: I'm editing the bug description to cover this situation. | 16:06 |
| jam | fbond: see the followuup on #227349 | 16:06 |
| jam | fbond: you might look at it before you change the description | 16:06 |
| colophon | Is there a way to have files ignored in some branches but not others which share the same repository. I have a project that includes some sample data that shouldn't be updated during the normal course of development but I would like to have it versioned | 16:07 |
| jam | colophon: well, each branch has its own .bzrigore | 16:07 |
| jam | though when you merge the changes to other files, it will pull along the .bzrignore files | 16:07 |
| jam | *howeve8 | 16:07 |
| jam | *however* | 16:07 |
| jam | if you have a file versioned, we don't pay attention to the ignore file | 16:08 |
| jam | so you could have all branches claim that the files are ignored | 16:08 |
| jam | and they just happen to be versioned in the one tree | 16:08 |
| jam | colophon: though it sounds like you may be asking for them to be versioned, but changes ignored in the other branches | 16:08 |
| jam | which isn't something we support yet | 16:08 |
| colophon | OK, I'll try to figure out how to split everything into two then | 16:09 |
| colophon | Thanks | 16:09 |
| fbond | jam: oops :) | 16:09 |
| fbond | jam: I'll fix it. | 16:10 |
| fbond | jam: Foo, launchpad doesn't seem to track intermediate changes to the description...? | 16:11 |
| fbond | Ah, I have it in an e-mail. | 16:11 |
| jam | fbond: I think it might, but i'm don't believe it exposes it | 16:12 |
| fbond | jam: bug #227349 | 16:14 |
| ubottu | Launchpad bug 227349 in bzr-loom "Should refuse to switch threads if doing so would cause a WT conflict" [Undecided,New] https://launchpad.net/bugs/227349 | 16:14 |
| fbond | My comment is mostly superfluous. | 16:14 |
| jam | fbond: seems reasonable | 16:15 |
| === cprov-lunch is now known as cprov | ||
| arj | hi | 17:44 |
| arj | I have two branches, one which is head and one that is stable. Mostly stable is == head, unless in release mode, in which, stable cherry picks patches from head. Now a release I want to sync these two branches again, but merging in stable from head creates conflicts. Why doesn't this just work? There was no changes to stable, other than the cherry picked patches | 17:46 |
| Vadi | How can I find out what revision is a branch at? I looked around the commands list but none report it | 17:54 |
| LeoNerd | bzr revno | 17:55 |
| Vadi | Thank you! | 17:55 |
| fullermd | arj: Because of the cherrypicks. | 17:56 |
| arj | fullermd: but that doesn't make sense | 17:57 |
| fullermd | Sense? This is the Internet! | 17:57 |
| arj | say I have 10 revisions in head. Stable is rev 4. I cherry pick 6 and 7 | 17:58 |
| arj | then I do, merge with head later | 17:58 |
| fullermd | Cherrypicks don't bring along any metadata; it's roughly equivalent to a diff | patch. So bzr doesn't know you cherrypicked anything; it's indistinguishable from making the changes manually. | 17:58 |
| arj | so it should just unroll 6 and 7 and do a full update | 17:58 |
| arj | oh :( | 17:59 |
| arj | that sucks, when will it be fixed? :) | 17:59 |
| fullermd | Not soon, I expect. It's a Moderately Hard Problem. | 17:59 |
| fullermd | AFAIK, the only systems that properly handle it are those like darcs, which tracks sets of patches rather than series of states. | 18:00 |
| arj | getting the full range of situations right might be moderately hard. But the case I just mentioned should be rather easy. And I don't this is a quite common case. | 18:01 |
| arj | s/don't/think/ | 18:01 |
| arj | the problem is that I have already mirrored the stable branch somewhere. So what is the easiest way to fix my stable branch? | 18:02 |
| fullermd | Well, if you have one small block of contiguous cherrypicks, it's not TOO hard. | 18:02 |
| fullermd | You can merge up to the rev before the cherrypicks, commit, merge the revs you cherrypicked, revert [since you already have the changes] and commit (which records the revs in your history), then merge the rest. | 18:03 |
| fullermd | (the same mechanism could work for bunches of noncontiguous cherrypicks, of course, but it gets REAL annoying quickly) | 18:03 |
| fullermd | Or you could just manually resolve the conflicts. If they're small, that can be quicker. | 18:04 |
| arj | hmm | 18:04 |
| arj | maybe a wrapper around bzr would be easier in the future | 18:04 |
| fullermd | I guess a third option would be to merge all the changes, and use revert to force the files to the way they are in the last rev of head. | 18:04 |
| fullermd | If you don't have any local changes in stable, that's probably the simplest. | 18:04 |
| fullermd | (or you do have local changes, but don't want to keep them) | 18:05 |
| arj | how do I do the last force thingy? | 18:05 |
| fullermd | Look up the revid of that rev in head, do the merge, then `bzr revert -rrevid:whateveritwas .` (in the root dir of the branch) | 18:05 |
| fullermd | You need the '.', otherwise revert will throw away the merge info. | 18:05 |
| fullermd | This way it just forces all the files to how they are in that rev, and blows away conflict stuff. | 18:06 |
| arj | hmm | 18:07 |
| arj | it seems like it looks for the revid in stable | 18:07 |
| arj | bzr: ERROR: Requested revision: u'revid:1608' does not exist in branch: BzrBranch5('file:///home/arj/bzr/mms-1.1.0-stable/') | 18:07 |
| fullermd | No, you want the revid (em@ail.addr-2008046235lbzehl or whatever), not the revno. | 18:07 |
| arj | 1608 is the revision of head I merged | 18:07 |
| fullermd | See `bzr revision-info`, or `bzr log --show-ids` | 18:08 |
| fullermd | The revision number will be different in stable than it is in head. And it won't have any revno in stable until after you've committed. | 18:08 |
| fullermd | But it should be accessible by the revid any time it's in the repo, which is is after you do the 'merge' even before you commit. | 18:09 |
| arj | ah that works | 18:09 |
| arj | thanks a lot! | 18:09 |
| dacresni | hey, does the bzr smart server have permissions? | 18:10 |
| MattCampbell | When using the bzr smart server over SSH (the only method I'm familiar with), it runs under whatever Unix account you tell bzr to log into via SSH. So it's subject to Unix file permissions. | 18:14 |
| dacresni | what about if windows users are loging into it? | 18:15 |
| MattCampbell | Is the server itself running Unix or Windows? | 18:15 |
| dacresni | windows | 18:15 |
| MattCampbell | Hmm, I'll have to let someone else answer. | 18:15 |
| dacresni | k | 18:15 |
| fullermd | The system itself provides no permission management or control at all (excepting that it may be run in read-only or read-write mode). | 18:17 |
| fullermd | So whatever limitations are provided by the OS environment around it are what you have. | 18:17 |
| dacresni | so i must use http auth on that directory on IIS | 18:17 |
| dacresni | ? | 18:18 |
| dacresni | (i wonder if mercurial can do better) | 18:18 |
| fullermd | Well, if you're working over ssh, http auth doesn't come into play. | 18:18 |
| dacresni | but if I don't want to isntall ssh on the server, | 18:18 |
| fullermd | But if you're using the HTTP smart server, yeah, whatever auth Apache provides is what you're running with. | 18:19 |
| dacresni | IIS | 18:19 |
| fullermd | And whatever permissions/restrictions are applied to CGI scripts are the limits of what you can do post-auth. | 18:19 |
| dacresni | post-auth? | 18:19 |
| fullermd | "Can I access this" vs. "What can I do once allowed to access" | 18:21 |
| dacresni | ah | 18:21 |
| fullermd | HTTP auth provides authentication. OS permissions (unix perms, ACL's, chroot's, blah blah blah) determine authorization. | 18:21 |
| dacresni | ah, ok that helps | 18:21 |
| MattCampbell | My suggestion, if you must run the server on a Windows box, would be to set up Linux of some kind in a VM on that box, maybe using VMware Server (free of charge), and use bzr+ssh inside the VM. | 18:22 |
| fullermd | Now, over a dumb server (plain HTTP), you can use the web server config to manage [some] authorization too. | 18:22 |
| fullermd | But with the smart server, every request shows up as a POST to a specific URL, so you can't get any finer-grained. | 18:22 |
| dacresni | AH, Neat | 18:23 |
| nysin | I maintain a modification to a program which switched from svn to bzr and now I'm left with a near-copy of that repository (I have both bzr and svn forms around, since I did a repository conversion on my end too) with its own revision history. I could (1) sacrifice that history, start fresh with a bzr branch/get/etc clone of the main repository, generate a big patch (or multiple little patches corresponding to the history wi | 18:23 |
| nysin | th synthetic timestamps? eh.) representing the entire delta, apply it to the new clone, and continue on and take advantage of bzr's merging abilities. Or (2) basically do bzr diff's on changes to remote repository and give up lots of good things, but keep revision history. Is this accurate and am I missing something? | 18:23 |
| fullermd | You may be able to use rebase to automate doing (1) but keeping the individual commits/timestamps/etc. | 18:24 |
| nysin | hm | 18:25 |
| * fullermd wanders off. | 18:25 | |
| dacresni | fullermd: sweet! everyone here that writes for the web has windows domain access to the webserver | 18:26 |
| Vadi | There's a typo in the bzr user guide (http://doc.bazaar-vcs.org/latest/en/user-guide/index.html), it says "Linix" near the bottom. | 18:42 |
| _paneb | bzr merge the.main.branch: does this merge the.main.branch into my local branch? | 19:11 |
| arj | yes | 19:13 |
| _paneb | then i would do commit to update the.main.branch? | 19:30 |
| arj | you merge | 19:30 |
| luks | what do you mean by 'to update'? | 19:31 |
| arj | and if you're happy with the merge, you commit in your local branch | 19:31 |
| _paneb | ok, suppose there is a main branch somewhere. i created a checkout from it and added some changes. then i want to commit those changes to the main branch | 19:32 |
| luks | then you just commit | 19:33 |
| awilkins | Yes, checkouts are bound to their parent branch | 19:34 |
| _paneb | ah yea right | 19:34 |
| _paneb | now, if i weren't using a checkout, how would it go? i would have to merge the main branch into my local one and then push the local one? | 19:35 |
| luks | commit and then push | 19:35 |
| _paneb | ok | 19:35 |
| luks | commit+push in a standalone branch is basically the same as commit in a checkout | 19:35 |
| _paneb | ok | 19:36 |
| luks | you only need to merge if the main branch has changed since you branched it | 19:36 |
| luks | and in that case, 'bzr push' would complain | 19:36 |
| _paneb | ah | 19:37 |
| _paneb | thank you | 19:37 |
| pbor | after a rebase, how can I turn all my locally committed changesets in a single changeset? | 20:16 |
| MattCampbell | What's the recommended way to install a recent version of bzr on Debian Etch? | 20:29 |
| MattCampbell | If I create branches from several existing directories, can I later combine those into a single branch containing those directories? | 20:55 |
| fullermd | Yes. | 20:55 |
| MattCampbell | So I suppose if I'm not sure about how to organize files and directories under version control, I should start off with several small branches and then combine later if that seems better. | 20:58 |
| fullermd | Yeah. Combining them is easier than splitting them up [without losing history]. | 20:59 |
| === samurai_ is now known as samurai | ||
| === bla2451 is now known as pygi | ||
| poolie | hello all | 23:47 |
| beuno | mornin' poolie | 23:47 |
| igc | morning all | 23:52 |
| igc | morning beuno | 23:52 |
| beuno | mornin' igc | 23:54 |
| Peng | So it seems going to the bzr+http smart server in a browser, doing a GET, returns a 404. I wish I had known that before | 23:58 |
| Peng | I spent ten minutes figuring out why it was broken, when I just wasn't accessing it right. :P | 23:59 |
| Peng | How'd I hit Enter in the middle of that? Shift, I guess. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!