[00:12] wow, bzr-colo is really nince [00:13] *nice === dOxxx is now known as dOxxx_away [08:11] hi guys [09:12] hi === ddaa1 is now known as ddaa [11:38] I have strange question! how to lock file in bazaar?! i couldn't find anything on the internet so i think i'm using the wrong keywords [11:40] Anyone? [11:43] lock? [11:45] yup [11:45] Kamping_Kaiser: why i'm unable to find any documentation regarding to this? [11:48] sinasalek1: because locking a file requires a central authority to record that one user has locked so everybody else can ask whether they can lock or not [11:49] sinasalek1: when working in a distributed env, there is no central authority, so can't implement locking [11:49] vila: So you meant the question is wrong? even if i used cnetralized workflow? [11:49] sinasalek1: not wrong, there are some cases when you still want to do that, but yes, this requires a centralized workflow [11:49] vila: really? [11:50] I mean, cases when you still want to do that? [11:50] vila: so it's supported ? [11:50] sinasalek1: bzr itself doesn't implement it, but there have been a few attempts to handle it via plugins [11:50] sinasalek1: I don't remember the references though :-/ [11:50] vila: Thanks that helped :) [11:51] ddaa: files in binary format like word or the like [11:51] * ddaa bends his mind into trying to see things this way [11:51] sinasalek1: but unless you're dealing with files that *can't* be merged properly, it's generally a better idea to avoid locking [11:51] * vila just loves when they do that :-/ [11:52] ddaa: yeah, doesn't really fit the distributed model isn't it ? [11:52] not just the distributed model [11:52] ddaa: but some people cared enough about it to start implementing it [11:53] after all those years immersed into a DVCS mindset, it's hard not to see it as a principle that locking is neither needed nor desirable. [11:53] ddaa: it boils down to how you handle concurrent edits or if you prefer to just avoid them [11:54] I kindaaaa see it now [11:54] it's a bit like checkouts, only more so. [11:55] stop me before I open the file for editing, not when I commit. [11:55] I don't see how to make that fit into the bzr model though. [11:57] first, it would require a new *branch* format [11:57] since it would be non-versioned branch-local data. [11:58] then a new tree format, to translate the lock into fs permissions [12:00] "bzr lock FILE" would acquire a write lock on the branch, and open, say ".bzr/branch/file-locks" [12:00] okay, I see it now [12:01] file-lock is a mapping of file ids to uuids. [12:01] bzr lock FILE adds line to file-lock, and record the uuid in the working tree [12:02] bzr unlock FILE checks if the working tree uuid matches that of the branch, and remove the lock [12:02] don't forget to record the whoami in a lock record too [12:02] maxb: same recipe as branch lock [12:02] need to identify the user, and be unique too [12:02] now, there must be guards in anything that can write to the branch tip [12:03] like commit, push, pull, etc. [12:04] that the user has a file lock on any file requiring locks that is modified by the delta [12:04] that means we also need an inventory data identifying "files requiring locks" [12:04] fuck [12:04] sorry [12:05] that's a really complicated feature to implement [12:05] it just got past my "I don't really want to think about it" threshold [12:07] and we don't have versioned file properties yet [12:07] so it would require another bit of working-tree metadata to identify file ids requiring locks [12:10] now, another riddle [12:10] after using "bzr branch", we can't do the locking anymore [12:11] at least, not properly [12:11] the user will still need to lock to edit the file, but it won't acquire the right lock [12:12] so, the working tree needs to record the URL of the branch that has the real lock [12:12] now, what happens when pulling a delta that changes that information? [12:13] gaaah! [12:13] vila: did anybody answer that one, yet? [12:15] now, there's another desirable feature [12:16] that's for a *branch* to take a file lock from another branch [12:16] so you can say "this file can only be modified on this feature branch, not on trunk" [12:17] ddaa: I don't remember the details, but AFAIR, they went with a pretty simple thing that appeared to "work for them" [12:17] I can imagine that. [12:18] There can be a world of difference between "simple enough that worksforme" and "robust enough for general use" [12:18] "simple enough that worksforme" can just be a pumpkin [12:19] and as far as bzr is concerned, it will be more profitable to support hooks for diffing and merging more of this binary formats [12:19] different use cases really [12:19] we already have the hooks for merge [12:19] * vila off for lunch [12:25] actually, the "lock location" info should be unversioned branch data too [12:26] and the "assign lock to another branch" is the same mechanism that should be used when locking to a heavy checkout. === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [18:40] How do I merge a change from downstream, back upstream? There seems to have been some confusion and someone has made an upstream change in the downstream version, i.e: code → deb → code-bugfix (→ code). I want to merge code-bugfix back into code without adding all the debianization, what is the best way to do this? [18:46] cherrypick merge? [19:06] maxb: Thanks, I'll try it. [19:41] maxb: Seem to be having some trouble. When I try cherry-pick merging I get "All changes applied successfully." (I'm running `bzr merge --rev 36..33 ../code-bugfix/ `). [19:42] 33..36 surely. [19:43] you want his changes included, not to back them out after they've already been committed [19:50] hey, does "bzr export ftp://[username]:[password]@ftp.domain.com work? [19:52] mgz: Ooops, I actually ran 33..36, then tried 36..33 (just in case I misunderstood the manual). So neither 33..36 nor 36..33 works. [19:55] do `bzr revert` then try again with --preview added? [19:57] i accidently delete everything in my working tree ... .bzr directory is still there, how do I get my working tree back? [19:58] also `bzr revert` provided you didn't commit your deletion. [19:58] thanks mgz !!! [19:58] what's the equivalent of "git co [hash value]" in bzr? [19:59] mgz: hi, I think I've updated my patch as requested, can you look at it again? https://code.edge.launchpad.net/~jameinel/bzr/2.3-filter-tests/+merge/33938 [19:59] i want to go to revision 6, the current revision is 12 === jam1 is now known as jam [19:59] `bzr update -r 6` [19:59] sure jam, I'll take a look. [20:01] ...when launchpad updates the diff, because I'm lazy [20:10] all looks reasonable, I'll run the tests locally as well. [20:11] I think the _report_* method additions won't be needed when the existing issue with how the bzr/testtools boundary works for exceptions, but it's easy to just remove them again when that's sorted [20:14] +is fixed [20:16] bt.test_selftest.TestSubunitLogDetails.test_success_has_no_log fails here, it does contain the log. [20:20] you appear to have just not changed addSuccess [20:31] mgz: I just didn't commit before my last push :) [20:31] :D [20:33] mgz: just push rev 5393 [20:33] I just pushed 5393 [20:33] pulling. [20:33] which should have a few more subunit permutations [20:35] okay, that's more like it. [20:36] ha, I see you gave in and made a generic testing class for test_selftest [20:36] mgz: yeah, you need something to do the permutations, and i was using it 2x [20:37] the --subunit stack is *quite* different from our regular stack [20:37] subunit doesn't inherit from testtools, for example [20:38] yep, it's a bit of a pain [20:45] mgz: I used --preview - it just returns a diff of the to-be merged changes. [20:45] JoshBrown: that was the point, are they the right changes? [20:46] mgz: No, I only want the code changes [20:46] if so, just do the same thing without --preview, then `bzr commit -m "Cherry pick ... changes from ..."` [20:46] The diff shows code and deb changes [20:47] so the deb changes were part of the same commit as the fix you want? [20:47] then you can just revert them before running commit [20:48] `bzr revert ./debian` [20:48] (or whatever) [21:01] jam: have put a comment in the mp, don't know if you want to tackle the annoying merge now [21:02] mgz: you mean submitting it? or what do you mean by 'annoying merge'? [21:03] yup, that. there have just been a few selftest changes lately, so there's always a conflict [21:04] thanks for the heads up [21:04] *glee* 2 conflicts [21:05] mgz: and yeah, I had tried to do some of it using TextTestResult or whatever, and it was a bit... joyless [21:06] we don't really want to be using that in bt.test_selftest at all I think, leave it for bb. [21:06] could just use some cleanup. [21:08] mgz: I find the current state still rather messy. Even without our extensions. [21:08] What goes on Result what goes on Case, what goes on Runner [21:08] and then the inconsistencies [21:08] yup. [21:09] testresult.expectedFailures is a list with different items than testresult.unexpectedSuccesses [21:09] (one has tuples of (test_id, reason) the other a list of [tests]) === BasicPRO is now known as BasicOSX [22:05] hi [22:05] i want to find out how many lines each developer on a project has written. [22:06] i'm doing a homework assignment at university with bzr and it's important that both developers have written an equal amount of lines ... [22:06] is that possible with bzr? [22:08] What a bizarre requirement... do you mean lines written total over history, or just lines in the current version? [22:09] If it's just the latter, you could figure it from annotate pretty easy. [22:11] i think it's over the total history [22:12] So, all you need is one partner who writes really bad code, and has to keep rewriting it? ;) [22:12] Anyway, it's certainly _conceptually_ possible. I don't know if anybody's written a plugin to do it though. [22:13] well... i don't think it's a fair requirement, either ... [22:14] i think 60:40 might be ok as well, but he doesn't want one of both to do nothing.. [22:14] and annotate shows only the lines in the current version? [22:15] Heck, if it's over history, you just need one guy to be SO bad the other guy has to write all his stuff, and *bam*, 50/50, even though he doesn't have a single line in the final version :> [22:15] Well, annotate shows the lines in any version you ask it. But it would take a lot of postprocessing work to figure a cumulative-lines-in-history from that. And many times more work than doing it below that. [22:16] ah, ok.. now i got what you were saying ;-) [22:16] If you were doing that, it would probably be easier to go from diffs of each revision than annotating each file/revision. [22:17] Well, a little anyway. Certainly a lot less redundant bzr churning at least. [22:17] Hm. If you wrote a rich-root-weave format for bzr, you could process it right out of the text storage pretty easily. Would be a little on the slow side though. [22:21] just hack something together with bzr annotate and wc, it's a dumb requirement that doesn't need a perfect solution [22:22] Hush, you. Writing a perfect solution would be WAY more fun than wasting time on classwork :p [22:23] :) [22:31] well as i'm not studying computer science, it doesn't have to be perfect at all ;) [22:51] what's the diff between bzr upload and bzr export ? [22:52] git__: Couple of things.. [22:52] git__: export doesn't let you push to a remote location. [22:53] git__: ..and doesn't let you export to a location to which you've already exported (it complains about a not being able to export to a non-empty directory. [22:53] git__: upload does supports both of those things. [22:54] git__: So export is what you use for a one-off sort of export, while upload is good for e.g. doing development locally and every once in a while pushing to a remote location, like a webserver. [22:55] thanks soren, you are very thorough with your answer, really appreciated !!! [22:55] git__: Sure.