[00:04] good morning [00:23] poolie, hey :) [00:24] poolie, right, morning at 1:25AM :) [00:24] hello pygi [00:24] poolie, any idea when we'll have the next sprint? :) [00:27] pygi, are you keen? [00:27] poolie, yesh, I wanna work on this cheezburger stuff [00:27] we'd talked about doing something again in early 2009, roughly a year from the last one [00:27] a lot of people poked me about it ... [00:28] poolie, as long as it's not during exams/papers season, I'm good =) [00:29] bzr just gave me a MemoryError: https://pastebin.canonical.com/9365/ [00:29] pygi: cheezburger? [00:29] poolie, bzr repositories hosting thingy [00:30] Oooh? [00:30] roughly, bzr equivalent to gitorious [00:31] jml: public channel private pastebin? [00:32] jml: but that looks like that "occasionally the sftp server sends random junk" message [00:32] bug [00:32] pygi, i've not heard of this before but it sounds cool [00:32] pygi, maybe you should come to UDS? [00:32] mwhudson: ungh [00:32] poolie, I'm trying, I applied for sponsorship ... [00:32] poolie, you think me will get accepted? [00:33] jml: unless its actually confidential, a public pastebin works better for this channel [00:33] (I didn't really mention cheezburger cause it's Bzr related, and not ubuntu, but I did mention I mentored for bzr two years ago) [00:33] anyhow, return os.read(self.proc.stdout.fileno(), count) [00:33] thats a strange line to memory error on [00:33] I wonder what count is [00:36] jml: is it repeatable? [00:36] * jml tries [00:38] jml: https://bugs.edge.launchpad.net/bzr/+bug/255292 [00:38] hmm [00:38] lifeless: yes it is. would you like to know the value of count? [00:39] * mwhudson things he would like to use bzrlib.graph._BreadthFirstSearcher [00:39] poolie, lets hope we do meet there [00:39] jml: not particularly, but I should I guess [00:39] pygi, i hadn't decided to go but i'm thinking about it [00:39] lifeless and abentley will [00:40] be there [00:40] poolie, decide then :) [00:40] so we can talk and then later on hack! [00:41] last two numbers are 1714499681 [00:41] 1714466917 [00:41] large numbers the twain of them. [00:41] poolie, I really hope I get sponsored :) [00:42] I did two years ago, same location, but had to decline it :-/ [00:42] jml: quite close large numbers [00:43] (they only differ in three bits) [00:45] jml: a 1.7GB index would be quite a sight [00:46] lifeless: indeed. [00:46] * jml updates the bug report [00:46] jml: do you have a 1.7GB index? [00:47] lifeless: no. [00:47] lifeless: unless bazaar multiplies the size when you push the branch up [00:47] lifeless: does branch.repository.get_parent_map take stacking into account? [00:48] lifeless: locally the repo is ~600mb and the branch is ~2mb. [00:48] (as in, will it return the same thing when branch is stacked on some other branch as when branch is not stacked?) [00:48] mwhudson: yes [00:49] cool [00:49] mwhudson: all public apis take stacking into account, or are buggy [00:49] lifeless: good to hear :) [00:50] oh hm, i was misreading things [00:50] hee hee [00:50] (good) [00:55] mwhudson: also any chain of public attributes/methods will be safe, except the obvious ones where you folllow a stacked relationship or some such [00:56] I'm working on bzr repo B, a larger bzr repo (called it A) wants to absorb my bzr repo B, how do I get my files into repo A and maintain the history/changelogs? [00:56] lifeless: i think i was scared unnecessarily by the way repository.get_graph mentions "stackedparentsprovider" [00:56] (although i think stackedparentsprovider is mostly something else?) [00:57] BasicOSX: bzr join [00:57] oh, ty, let me research it [00:58] poolie, correction: cheezburger is roughly bzr's equivalent to gitosis, not gitorious (just noticed the "bug") [00:58] hm, what's the difference? [00:59] gitorious is with web UI and all that, something like Launchpad for git [00:59] gitosis is server-side stuff for creating/managing repos and access to them, and can manage things like gitweb to show repositories on web [01:17] mwhudson: StackedParentsProvider predates branch stacking. Not really related. [01:17] abentley: right [01:18] lifeless: daniel has heaps of patches up for review for pqm [01:18] http://blog.daniel-watkins.co.uk/updated_state_of_pqm.html [01:18] can we get them unblocked somehow? [01:18] It's stacking on a much more temporary basis, so that you can find the LCA when neither repository has all the relevant revisions. [01:19] spiv: ping [01:19] hello abentley [01:19] abentley: pong [01:19] poolie: hi. [01:19] spiv: How do I use RemoteRepository.leave_lock [01:19] _in_place? [01:20] The same way as for other repos, hopefully :) [01:20] spiv: I am doing a branch_implementations test, and it fails with RemoteRepository only, because RemoteRepository raises NotImplemented. [01:20] Oh, hmm. [01:21] I bet it's because it's because remote pack repos don't return lock tokens. [01:21] spiv: The lock token is '', and this evaluates to boolean false. [01:21] Right. [01:21] The test there probably should be for "if self._lock_token is not None" [01:22] Hmm. [01:22] Or you could just notice that repo.lock_write() doesn't return a token; and thus indicates that the repo doesn't support this interface. [01:22] support which interface? [01:23] lock_write(lock_token=foo) / leave_lock_in_place / dont_leave_lock_in_place [01:23] Or maybe I should ask, are we saying the RemoteRepository doesn't support the interface, or that the actual repository doesn't? [01:23] The latter. [01:24] (RemoteRepository is the only repository class that varies this by instance, unsurprisingly) [01:24] Pack repositories don't raise NotImplementedError for this, AFAIK. [01:26] Yeah, there does seem to be an unfortunate behaviour difference there, but IIRC they are both providing reasonable behaviours. [01:27] There's a lot of per_branch/test_locking.py tests that already inspect the return value of branch.lock_write(). [01:27] I tell a lie. It does raise. [01:27] Ah, even better :) [01:28] I'm about to file a job description for BzrEclipse regarding "bzr tag support". Where do you guys think would be the best place to put it? Together with "commit" or as a separate option under "project -> team -> Tag"? [01:28] FWIW, the docstring for leave_lock_in_place says "If lock_write doesn't return a token, then this method is not supported [01:28] " [01:28] spiv: I'm trying to fix a test that breaks a lock. [01:28] Together with commit would make more sense I think [01:28] That test does not release the original lock. [01:29] I want to use leave_lock_in_place, then release the lock. [01:29] So should I actually be saying the test is NotApplicable for repos whose write_lock returns None? [01:30] Which test? [01:31] branch_implementations.TestBreakLock.test_unlocked_repo_locked [01:31] If the test needs to use leave_lock_in_place to create a lock that needs breaking, then it definitely should skip with something like NotApplicable if lock_write returns None. [01:32] spiv: Great, thanks. [01:32] (or find another way to make a broken lock) [01:33] spiv: But the *reason* is that the repository cannot create physical locks, right? [01:33] And therefore, there's nothing to leave behind or break. [01:33] poolie: the next major one was merge-directives, which I reviewed but hasn't been updated AFAIK [01:33] abentley: I think so, yes. [01:34] Although, that's not entirely true for packs. There is that names list lock. [01:34] abentley: the shame here is that RemoteRepository does support this interface, it's just that the pack repo behind it doesn't. [01:35] I see. I just found it very confusing trying to understand why it was doing what it was doing. [01:35] So ideally we'd run this test against with a slightly different RemoteBranch scenario: RemoteBranch + dirstate-tags format, say. I'm not sure it's worth the effort to arrange that. [01:35] spiv: I hear you. [01:35] abentley: the names list lock is rather more transparently managed though, because there is atomic-insert of a bunch of data, though you probably know this :) [01:36] lifeless: Don't bet on it :-) [01:36] Also, hmm... [01:37] I would have expected that a RemoteBranch would still return a lock token, even if the RemoteRepo' underlying repo doesn't. [01:38] spiv: the branch should yes [01:39] Oh, but this test is doing branch.repository.lock_write() etc, not branch.lock_write(). [01:39] So that makes sense. [01:57] Tried to bzr join, error about KnitPackRepository, so I ' bzr upgrade --rich-root-pack' then tried to join, 'bzr: ERROR: Cannot join debian/. Trees have the same root' [02:00] BasicOSX: There's a reason join is a hidden command. [02:00] understood, I'll research more, sorry to bother [02:01] BasicOSX: Also, you should understand that --rich-root-pack is a one-way conversion. [02:01] For your needs, the merge-into plugin sounds more appropriate. [02:02] researching that ... ty [02:08] thank you abentley that did exactly what I wanted [02:08] BasicOSX: great [02:24] abentley: hi [02:24] i'd like to get the lca shape merge thing unblocked === fta_ is now known as fta [02:25] this seems like a case where our reviews are kind of slowing us down [02:25] i do really appreciate you reading it, in your own time i know [02:27] Wow, PQM scares me even more now... === vk5foss is now known as kgoetz [02:43] poolie: jam said he'd call me about that. [02:46] hi guys, after I issued 'bzr update', I encountered this bug -> http://pastebin.ca/1207947 [02:48] any idea, what causes and why does that error resumes? [02:49] poolie: my problem with the patch is that I feel it degrades design design clarity by changing the model without changing the class to match. [02:53] toytoy: so it's running out of memory trying to update the dirstate [02:53] toytoy, i'd start by trying to upgrade to 1.6.1 or 1.7rc2 [02:54] abentley: so i can see how it would be cleaner with those changes [02:55] i'm just wondering if it would be better to merge it as is first basically [02:55] poolie: you mean the memory is full or sorry I am not sure why would my memory would be full [02:55] toytoy: is it a very large tree, or something with a large file in it? [02:56] the C extensions sometimes raise MemoryError on corrupt dirstate [02:56] poolie: oh i see, yeah i think so, so what is your best advise? lessen the files inside the trees? [02:57] toytoy: yeah it's too large? [02:58] toytoy: you are running a very old version of Bazaar. Really, you should upgrade to the current release and try again. [02:58] poolie: btw, what do you mean by too large? i mean how many size do you expect a 'too large' to you? [02:58] 500000 paths would be pushing it [02:58] poolie: I'm ambivalent. On the one hand, we can always fix it later. On the other, we could have fixed it by now. [02:59] abentley: i think what may be happening here is that we feel like if we don't catch things in review we won't fix them [02:59] however, [03:00] lifeless: that's really too big, but mine is not so. let me check the trunk [03:00] trunk's size [03:00] it's making the cycle time for reviews longer, and i think it can be discouraging for the submitter (and might be in this case) [03:00] it's just 163MB so that might not too big right? [03:01] I think you're right about what's happening here. [03:01] but yeah, my bazaar version at server is 1.3.1 [03:01] it may also make things linger in the queue because they don't get a crisp decision [03:02] i think, all other things being equal, if it takes X additional work to clean it up [03:02] it would be preferable to land the patch and then do X, [03:02] The attempt to review thoroughly is part of them problem? [03:02] than otherwise [03:03] i'm assuming these are cleanups not outright bugs [03:03] hm [03:03] do you think so? [03:03] i wouldn't say so [03:03] Well, it does make the cycle time for reviews longer. What did you mean, then? [03:04] ah, what i meant by "it" is asking for things to be resubmitted to be cleaner or tested in a different way [03:05] Ah, increasing the number of cycles, then. [03:07] poolie: If we change this from requiring resubmissions to asking for followup patches, should we try to ensure that the followups happen? [03:07] And if we did, how? [03:15] (back, with coffee) [03:15] yes, this would be trying to have more but smaller cycles [03:16] so one proposed idea is to get people to file bugs for the followon work [03:16] if people want to do it good luck to them but i don't think it's a very good general solution because [03:17] i think they're often too fuzzy to be good bugs - they are not falsifiable [03:17] and, also, just filing a bug doesn't give much assurance that it will actually get done [03:18] it would be weird to mark them as 'critical' and objectively they're not [03:18] but that seems to be the priority we're giving them by blocking out a high-priority fix until they're done [03:20] i think the core of it is just that people need to have time to make those cleanups [03:20] remembering what they have to do is not hard if they get to do them soon (within a few days) [03:20] and if they don't have time to do them soon, no record keeping system will help [03:22] Similarly, we could mark them in Bundle Buggy. [03:23] They would show up in peoples' 'todo' tab, even after they were merged. [03:23] mm [03:23] or we could make some more formal use of todo comments in the code [03:24] but - i hadn't realized it til talking to you - the record keeping is not the main issue, i think [03:26] Well, one issue is that in the short term, the follow-ups appear to have much lower priority than the original patch. [03:27] btw i can call if you'd rather talk on the phone [03:27] Sure, maybe that would work better. [03:27] skype or pots? [03:27] Skype's good. [03:28] lol skype [03:30] hi people [03:30] if I have rev_id x in branch 1, how do I find the mainline rev_no on branch 2 where rev_id x was introduced? [03:35] poolie: btw, I'm reasonably strongly negative on trading 'correct before landing' for 'please follow up' :- we already have 'please follow up' merges permitted; the process allows that and people use it [03:35] thumper: The simplest way is just to branch at that rev, and see what revno you get. [03:35] poolie: when reviewers ask for 'correct before landing' I believe thats because they assess that as the best route forward [03:35] lifeless, do you want to join us? [03:36] poolie: If you are talking about the weighting different reviewers have, then sure [03:36] poolie: no, I am just doing lunch, then back to getting status purged [03:37] please do consider though that the current process seems to me to allow what you are talking about. [03:37] fullermd: that's not going to tell me the right revno [03:37] fullermd: and also I'm really wanting to do this through bzrlib [03:38] lifeless: this is a bit of a case of "what you're asking for is either wrong or is trivial"? [03:38] poolie: ugh. review process is hard and complex; I'm just giving my input into your analysis. Once status is done I'd be delighted to discuss more. [03:38] thumper: Sure it will. If that revision is the head, the revno will always be the same. [03:39] thumper: I dunno bzrlib near well enough to say in there. I presume you could tell the revno-building function to pretend that rev was the head and just get the number directly. [03:39] fullermd: uh? [03:39] you have revid A [03:39] fullermd: I think you misunderstood the question [03:39] in a branch, you add 17 revisions on top of A [03:39] fullermd: b1 was branched from b2 at revno 3, b1 has 4 commits and has revno 7 as head. b2 has x commits one of which introduces b1 [03:40] in trunk, you merge these 17 revisions and commit [03:40] you want the answer to be A + 1 [03:41] Oh. [03:53] I'm reading on jelmer's bzr-svn FAQ page that one can use stacked branches for large SVN repos [03:53] I'm not exactly sure what a stacked branch would do [03:53] are you "stacking" on the svn repo? [03:58] poolie: what would have let me express my opinion without it being 'either wrong or trivial' ? I didn't say or suggest it was easy, and I was clear that it was my opinion [04:01] LaserJock: yes [04:05] mwhudson: there is a method on branch I think [04:05] thumper: ^ [04:11] hmm, this is still gonna take forever, KDE's svn is *huge* [04:12] lifeless, would that be _gen_revno_map ? [04:12] I mean, get_revision_id_to_revno_map [05:46] ok, full test running and then submit time [06:04] lifeless: so, basically i'm suggesting that we should look harder at cases where patches are being asked to resubmit when they are not actually wrong === AnMaster_ is now known as AnMaster === beaumonta is now known as abeaumont [06:56] hi aal [06:56] :-/ all [06:57] hi vila [07:03] hello vila [07:31] Does anyone know if there is a similar functionality like the q*-commands of mercurial? (They allow to manage and version-control patches on a patch-stack) [07:31] jonnydee: yes, see bzr-loom === Spaz_ is now known as Guest95388 [07:32] oh, that was a pretty fast answer :) thanks for your help :) [07:32] let us know how you go [07:32] ok, I'll let you know === Guest95388 is now known as Spaz_ === Spaz_ is now known as Guest55182 === Guest55182 is now known as Spaz_ === Spaz_ is now known as Guest4451 === Guest4451 is now known as Spaz_ [08:06] hey all :) [08:16] How do I move my .bzr dir out of my project. "bzr init project" create project/.bzr and I don't want it there but in ~/backup/bazaars/ for backup reasons [08:18] ngnp: Err.. I don't you can. You could try to move it and symlink it, but bzr would probably freak out. [08:18] ngnp: You could move it to ~/backups/bazaar and then make "project" a lightweight checkout of that. [08:18] a simpler solution is to make project/ a lightweight checkout of a branch in ~/backup/bazaars [08:18] At Froscon some guy claimed i could be done [08:19] ngnp: Then ask him. :P [08:19] Depending on how your backup system works, maybe you could just put a symlink to the .bzr dir in ~/backup/foo ? [08:19] Peng_: bob2: can i do a lightweight checkout with the file:// protocol? [08:19] ngnp: yup [08:19] But my guess is the Froscon guy was thinking of lightweight checkouts. [08:20] Or he was weird. :D [08:20] thanks guy ... i'll check it out ... dunno how to do a lightway one [08:20] http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-checkouts [08:20] no he was not weird .... worked for sun afaik ... they are not weird guys [08:20] spiv: :-) [08:22] ngnp: if you get stuck, feel free to ask for help in here. [08:22] thanks [08:24] lifeless: The last two bzr.dev commits announced on bazaar-commits@ don't seem to be published yet. Can you check if there's something awry at PQM's end? [08:27] i'm not sure on the terminology, but here is the situation. I have a few generic programs (web sites) which i want to then take copies of to make clients sites, but i want an easy way, for me to say fix a bug or add some new function to the generic version, and then be able to pull that change down into the specialized ones. What is the correct terminology for this (is it upsteam?) and can anyone point me at some workflows / descriptions on [08:28] a_c_m: your text got cut off at "workflows / descriptions on". [08:29] / descriptions on how to do this? [08:29] :) === Spaz_ is now known as Guest35839 [08:30] a_c_m: But it sounds like you could make the "generic" version a branch called "trunk", and have the specialised versions be branches off the trunk. You'd then merge the trunk into the branches when appropriate. [08:30] (You don't have to call it "trunk", but it's a convention that seems to fit your situation ok) [08:31] spiv: right, except ideally the projects would be self contained, with only some dev's having commit access to some projects etc... is this still possible with branches ? [08:32] Well, it's not possible any other way but with branches ;) [08:32] a_c_m: in bzr, you can't version anything without using branches :) [08:33] So your question is effectively "is this still possible with bzr?" :) [08:33] spiv: I still don't get it ... I'm new to bzr, lost a day work by 'eclipse/cvs replace with head' ... I understand the 'normal' commands but setting things up is brand new :-( ... haven't created a branch yet. [08:33] spiv: humm ok, but in that case, can branches have different read-write rights? [08:34] Commit access is generally managed with regular filesystem permissions. [08:34] spiv: ahh ok, that might work [08:36] * a_c_m is also going to be trying to play with commit hooks ! [08:36] ngnp: so, the key thing with lightweight checkouts is that you can make a "branch" in one location, and make a "checkout" of that branch somewhere else. [08:37] spiv: I misread some part of the url ... i now have a working checkout ... let me test some more [08:37] thanks btw [08:37] ngnp: a branch in bzr is the thing that tracks the history; i.e. "the current version is revision ABC". [08:39] ngnp: so for instance if you are starting a new project, you could do "bzr init mybranch; bzr checkout --lightweight mybranch mycheckout". Then all the commits etc you do in "mycheckout" will be recorded in the branch at mybranch. [08:39] ngnp: ah cool. [08:40] I still have to get used with this D in drcs :p [08:50] spiv: thanks ... I think I get to an understanding with bzr ... he now listens somewhat to my commands :p [08:52] * ngnp missed some documentation about a workflow that is working in conjunction with another vcs like cvs or subversion. That is making sure the .bzr is not committed into cvs/subversion and not overwritten by a 'cvs replace from head' [08:56] ngnp: Off the top of my head, it'd probably be enough to make bzr ignore 'CVS', and make cvs ignore '.bzr'? [08:57] a_c_m: can we upgrade these pages http://drupal.org/node/45368 together? [08:57] hey ngnp [08:57] i will help where i can for sure [08:57] spiv: me stupid ... you are so right :-) [08:58] .cvsignore [08:59] hmm ... but that does not prevent a 'replace from head' if i'm not in control of the cvs ... which is the case ... I do some patches for drupal as an anonymous cvs user ... [09:00] i'm trying to build an "uber" system, PQM to check against coding standards (and perhaps even coder) before commiting [09:00] a_c_m: after I have this cvs/bzr workflow a little in place i'll update those pages [09:00] a_c_m: auto coder ... is that possible? (sorry for the drupal talk) [09:01] ngnp: http://www.trellon.com/blog/daily-quality-control-checks-coder [09:02] a_c_m: thanks ... have you tried drush_mm too? [09:04] not yet === sabdf1 is now known as sabdfl === mneptok_ is now known as mneptok [10:18] lifeless: ping, aronud again? came back at about 4:50am (in europe atm), and went to bed instead of responding :) [10:53] Hrm... [10:53] bzr baz-import => This command is disabled. Please install PyBaz. [10:53] apt-get install pybaz => E: Package pybaz has no installation candidate [11:06] hello [11:06] is there in bzr something equivalent to git rebase? [11:08] Stavros: there's a bzr-rebase plugin [11:09] james_w: ah, thanks [11:10] actually i want to branch some official code and make some changes to it, keeping up with the official version. what's the best way to do that? [11:11] get a branch of the code and work on it, and occaisionally "bzr merge" the official version [11:11] ah, i don't need rebase then? [11:11] you could use rebase, but they will both do what you want [11:12] great, thanks [11:12] they will just do it in slightly different ways [11:12] hmm yes [11:13] i'm looking to keep my drupal installation up to date, so i figured i can pull from their repo, but i have some local changes [12:02] siretart: hi, would you be available for sponsoring an upload today? [12:04] james_w: sure [12:04] siretart: great, thanks. Do you have time now, or would you prefer to wait until after work? [12:05] james_w: perhaps you can sign and upload to alioth, and I'll rebuild and upload it to debian? [12:05] siretart: that works for me. [12:13] siretart: they're in /srv/alioth.debian.org/chroot/home/groups/pkg-bazaar/htdocs/2.0.1 [12:14] siretart: targeted at experimental [12:14] siretart: I would like this version in Intrepid, is a sync request going to be processed in a timely manner do you think? Or should a fakesync be done? [12:16] it depends on how hard you hit the archive admins ;) [12:18] Does bzr have the equivalent of tla/baz's "sync-tree".. Ie. pretend I have a commit when really I don't...? [12:19] I have two longlived branches that I crossmerge a lot; it would be nice to be able to ignore all the merges in one side on the other [12:20] .oO( Mm.. I suppose merge + revert might do it... ) [12:28] james_w: is the Vcs-Bzr location in debian/control up to date? it seems the last commit there was in march [12:28] siretart: no, you are correct === thekorn_ is now known as thekorn [12:30] LeoNerd: I tend to pull when I can, so if I know I've merged on my laptop, and haven't committed recently on the desktop, I pull from the laptop. [12:30] LeoNerd: that kind of thing [12:30] Kinnison: Ya.. this is for two branches of some code that's quite diverged between them, for the last.. er.. 4 years [12:31] siretart: fixed packages uploaded [12:32] LeoNerd: aah, :) === mark2 is now known as markh [13:29] siretart: thanks a lot. [13:29] you're welcome! [13:31] hello [13:31] will bzrtools ever be included in the repo so there aren't broken dependencies? === bac_afk is now known as bac [13:48] james_w:ping [13:48] hey jelmer [13:49] james_w, hi! [13:49] james_w, I noticed the function that exports tarballs is a bit simpler now in bzr [13:49] james_w, I was wondering whether bzr-builddeb could perhaps just call that directly and override the last modification time? === Pilky_ is now known as Pilky [13:50] jelmer: perhaps, I haven't looked at the changes [13:52] james_w, you have no objections to calling the tarball creating function directly and bypassing the export infrastructure though? [13:53] jelmer: ah, I think I get it now. I'd have to see the patch really, but I have no objection on principle. [13:53] jelmer: the only think would be that it ignores .bzr* as the export code does [13:56] james_w, It's still exercising that code [13:56] http://samba.org/~jelmer/bzr-builddeb-tar-exporter.diff [13:58] jelmer: I see "def tar_exporter(tree, dest, root, subdir, compression=None):" [13:58] I've got a patch for bzr.dev as well that allows overriding "now" [13:59] ah [13:59] once that patch is in bzr.dev I don't really care how the builddeb bit is done, so your patch would be fine [13:59] cool, thanks [14:00] jelmer: does the bzr.dev patch also use the time from the tree if it is not overridden? [14:00] it uses the time.time() as was done previously [14:01] ok [14:01] it could use tree.get_file_mtime() instead [14:02] Hmm, I wasn't aware of that function [14:03] When using that, bzr-builddeb wouldn't need patching anyway [14:03] for revision trees I think it just backs on to the timestamp of the revision [14:07] ah, but that is too slow for real use.. [14:07] hmm [14:07] * jelmer gives up === mw|out is now known as mw [14:19] what do I need to do to move the TREE_ROOT? [14:20] I tried setting set_root_id and deleting the former root folder, but that throws exceptions. === TheMuso_ is now known as TheMuso [14:37] Hi all, I have been evaluating Bazaar, and want to get away from CVS. [14:37] One nice thing about CVS was that I understood how it represented files and revisions and subdirectories etc. and therefore what it might be able to do for me. [14:37] Does anyone know where I could find similar info about Bazaar without attempting to grok the source? === cody-somerville_ is now known as cody-somerville [14:44] pysquared, you may want to look in doc/developer/ === cody-somerville is now known as cody-somerville_ [14:44] *-format.txt in particular === cody-somerville_ is now known as cody-somerville [14:46] jelmer, thanks, will do [15:04] abentley: In the commit that I saw, there was a new file called '' with the fileid TREE_ROOT created and the old '', with tree_root-* deleted. But when I try changing the root_id and deleting '', it throws an exception [15:23] guys, I manually installed bzr latest (1.6) on a Debian stable. [15:23] then I 'bzr branch sftp://strk@......' [15:23] modified, commit [15:23] and (wow: commit was incredibly fast) [15:23] well, now I pull from other machines and my changes are not there [15:23] no wonder commit was fast :) [15:23] so, hints on how to find out what happened ? bzr status shows no changes. [15:25] on push: bzr: ERROR: These branches have diverged. Try using "merge" and then "push". [15:25] so, does it mean my commits were "offline" ? [15:31] strk: your commits are always offline, that's the nature of DVCS [15:32] strk: I'd try a pull (to get the newest changes), merge and then a push. [15:33] strk: if you "bzr branch" instead of "bzr commit" then all commits are offline, "bzr bind" will bind your branch to the master branch so that they are no longer offline by default [15:34] bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/". [15:35] strk: that was for the bind? [15:35] This Quick Start Card is not a quick start http://doc.bazaar-vcs.org/bzr.dev/en/quick-reference/quick-start-summary.svg as I do not understand ie bzr branch mp myproject ... how to make this better? File a bug? [15:36] ngnp: file a patch would be more effective :) [15:36] how? I'm a newbie to bzr [15:37] ngnp: bzr branch np mayproject branches the repo in the mp directory to the myproject directory. [15:37] james_w: nope, that was for push. Trying bind now. [15:37] ngnp: basically, this is a quick reference, not a quick start tutorial. It's just useful then you know how things work, but forgot the commands. [15:38] Leonidas: I know after testing ... but it should be more like "bzr branck myproject newproject" [15:38] still, the bind gave me no automatic commit of the pending changes [15:38] ngnp: download the file, edit it, run diff and create a bug with a patch added to it. [15:38] and push still gives me "Operation denied" [15:39]