[00:12] <poolie> wow, bzr-colo is really nince
[00:13] <poolie> *nice
[08:11] <cheater99> hi guys
[09:12] <poolie> hi
[11:38] <sinasalek1> 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] <sinasalek1> Anyone?
[11:43] <Kamping_Kaiser> lock?
[11:45] <sinasalek1> yup
[11:45] <sinasalek1> Kamping_Kaiser: why i'm unable to find any documentation regarding to this?
[11:48] <vila> 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] <vila> sinasalek1: when working in a distributed env, there is no central authority, so can't implement locking
[11:49] <sinasalek1> vila: So you meant the question is wrong? even if i used cnetralized workflow?
[11:49] <vila> sinasalek1: not wrong, there are some cases when you still want to do that, but yes, this requires a centralized workflow
[11:49] <ddaa> vila: really?
[11:50] <ddaa> I mean, cases when you still want to do that?
[11:50] <sinasalek1> vila: so it's supported ?
[11:50] <vila> sinasalek1: bzr itself doesn't implement it, but there have been a few attempts to handle it via plugins
[11:50] <vila> sinasalek1: I don't remember the references though :-/
[11:50] <sinasalek1> vila: Thanks that helped :)
[11:51] <vila> 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] <vila> 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] <vila> ddaa: yeah, doesn't really fit the distributed model isn't it ?
[11:52] <ddaa> not just the distributed model
[11:52] <vila> ddaa: but some people cared enough about it to start implementing it
[11:53] <ddaa> 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] <vila> ddaa: it boils down to how you handle concurrent edits or if you prefer to just avoid them
[11:54] <ddaa> I kindaaaa see it now
[11:54] <ddaa> it's a bit like checkouts, only more so.
[11:55] <ddaa> stop me before I open the file for editing, not when I commit.
[11:55] <ddaa> I don't see how to make that fit into the bzr model though.
[11:57] <ddaa> first, it would require a new *branch* format
[11:57] <ddaa> since it would be non-versioned branch-local data.
[11:58] <ddaa> then a new tree format, to translate the lock into fs permissions
[12:00] <ddaa> "bzr lock FILE" would acquire a write lock on the branch, and open, say ".bzr/branch/file-locks"
[12:00] <ddaa> okay, I see it now
[12:01] <ddaa> file-lock is a mapping of file ids to uuids.
[12:01] <ddaa> bzr lock FILE adds line to file-lock, and record the uuid in the working tree
[12:02] <ddaa> bzr unlock FILE checks if the working tree uuid matches that of the branch, and remove the lock
[12:02] <maxb> don't forget to record the whoami in a lock record too
[12:02] <ddaa> maxb: same recipe as branch lock
[12:02] <ddaa> need to identify the user, and be unique too
[12:02] <ddaa> now, there must be guards in anything that can write to the branch tip
[12:03] <ddaa> like commit, push, pull, etc.
[12:04] <ddaa> that the user has a file lock on any file requiring locks that is modified by the delta
[12:04] <ddaa> that means we also need an inventory data identifying "files requiring locks"
[12:04] <ddaa> fuck
[12:04] <ddaa> sorry
[12:05] <ddaa> that's a really complicated feature to implement
[12:05] <ddaa> it just got past my "I don't really want to think about it" threshold
[12:07] <ddaa> and we don't have versioned file properties yet
[12:07] <ddaa> so it would require another bit of working-tree metadata to identify file ids requiring locks
[12:10] <ddaa> now, another riddle
[12:10] <ddaa> after using "bzr branch", we can't do the locking anymore
[12:11] <ddaa> at least, not properly
[12:11] <ddaa> the user will still need to lock to edit the file, but it won't acquire the right lock
[12:12] <ddaa> so, the working tree needs to record the URL of the branch that has the real lock
[12:12] <ddaa> now, what happens when pulling a delta that changes that information?
[12:13] <ddaa> gaaah!
[12:13] <ddaa> vila: did anybody answer that one, yet?
[12:15] <ddaa> now, there's another desirable feature
[12:16] <ddaa> that's for a *branch* to take a file lock from another branch
[12:16] <ddaa> so you can say "this file can only be modified on this feature branch, not on trunk"
[12:17] <vila> ddaa: I don't remember the details, but AFAIR, they went with a pretty simple thing that appeared to "work for them"
[12:17] <ddaa> I can imagine that.
[12:18] <ddaa> There can be a world of difference between "simple enough that worksforme" and "robust enough for general use"
[12:18] <ddaa> "simple enough that worksforme" can just be a pumpkin
[12:19] <vila> 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] <ddaa> different use cases really
[12:19] <vila> we already have the hooks for merge
[12:19]  * vila off for lunch
[12:25] <ddaa> actually, the "lock location" info should be unversioned branch data too
[12:26] <ddaa> and the "assign lock to another branch" is the same mechanism that should be used when locking to a heavy checkout.
[18:40] <JoshBrown> 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] <maxb> cherrypick merge?
[19:06] <JoshBrown> maxb: Thanks, I'll try it.
[19:41] <JoshBrown> 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] <mgz> 33..36 surely.
[19:43] <mgz> you want his changes included, not to back them out after they've already been committed
[19:50] <git__> hey, does "bzr export ftp://[username]:[password]@ftp.domain.com  work?
[19:52] <JoshBrown> 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] <mgz> do `bzr revert` then try again with --preview added?
[19:57] <git__> i accidently delete everything in my working tree ... .bzr directory is still there, how do I get my working tree back?
[19:58] <mgz> also `bzr revert` provided you didn't commit your deletion.
[19:58] <git__> thanks mgz !!!
[19:58] <git__> what's the equivalent of "git co [hash value]" in bzr?
[19:59] <jam1> 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] <git__> i want to go to revision 6, the current revision is 12
[19:59] <mgz> `bzr update -r 6`
[19:59] <mgz> sure jam, I'll take a look.
[20:01] <mgz> ...when launchpad updates the diff, because I'm lazy
[20:10] <mgz> all looks reasonable, I'll run the tests locally as well.
[20:11] <mgz> 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] <mgz> +is fixed
[20:16] <mgz> bt.test_selftest.TestSubunitLogDetails.test_success_has_no_log fails here, it does contain the log.
[20:20] <mgz> you appear to have just not changed addSuccess
[20:31] <jam> mgz: I just didn't commit before my last push :)
[20:31] <mgz> :D
[20:33] <jam> mgz: just push rev 5393
[20:33] <jam> I just pushed 5393
[20:33] <mgz> pulling.
[20:33] <jam> which should have a few more subunit permutations
[20:35] <mgz> okay, that's more like it.
[20:36] <mgz> ha, I see you gave in and made a generic testing class for test_selftest
[20:36] <jam> mgz: yeah, you need something to do the permutations, and i was using it 2x
[20:37] <jam> the --subunit stack is *quite* different from our regular stack
[20:37] <jam> subunit doesn't inherit from testtools, for example
[20:38] <mgz> yep, it's a bit of a pain
[20:45] <JoshBrown> mgz: I used --preview - it just returns a diff of the to-be merged changes.
[20:45] <mgz> JoshBrown: that was the point, are they the right changes?
[20:46] <JoshBrown> mgz: No, I only want the code changes
[20:46] <mgz> if so, just do the same thing without --preview, then `bzr commit -m "Cherry pick ... changes from ..."`
[20:46] <JoshBrown> The diff shows code and deb changes
[20:47] <mgz> so the deb changes were part of the same commit as the fix you want?
[20:47] <mgz> then you can just revert them before running commit
[20:48] <mgz> `bzr revert ./debian`
[20:48] <mgz> (or whatever)
[21:01] <mgz> jam: have put a comment in the mp, don't know if you want to tackle the annoying merge now
[21:02] <jam> mgz: you mean submitting it? or what do you mean by 'annoying merge'?
[21:03] <mgz> yup, that. there have just been a few selftest changes lately, so there's always a conflict
[21:04] <jam> thanks for the heads up
[21:04] <jam> *glee* 2 conflicts
[21:05] <jam> mgz: and yeah, I had tried to do some of it using TextTestResult or whatever, and it was a bit... joyless
[21:06] <mgz> we don't really want to be using that in bt.test_selftest at all I think, leave it for bb.
[21:06] <mgz> could just use some cleanup.
[21:08] <jam> mgz: I find the current state still rather messy. Even without our extensions.
[21:08] <jam> What goes on Result what goes on Case, what goes on Runner
[21:08] <jam> and then the inconsistencies
[21:08] <mgz> yup.
[21:09] <jam> testresult.expectedFailures is a list with different items than testresult.unexpectedSuccesses
[21:09] <jam> (one has tuples of (test_id, reason) the other a list of [tests])
[22:05] <swebo> hi
[22:05] <swebo> i want to find out how many lines each developer on a project has written.
[22:06] <swebo> 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] <swebo> is that possible with bzr?
[22:08] <fullermd> What a bizarre requirement...   do you mean lines written total over history, or just lines in the current version?
[22:09] <fullermd> If it's just the latter, you could figure it from annotate pretty easy.
[22:11] <swebo> i think it's over the total history
[22:12] <fullermd> So, all you need is one partner who writes really bad code, and has to keep rewriting it?   ;)
[22:12] <fullermd> Anyway, it's certainly _conceptually_ possible.  I don't know if anybody's written a plugin to do it though.
[22:13] <swebo> well... i don't think it's a fair requirement, either ...
[22:14] <swebo> i think 60:40 might be ok as well, but he doesn't want one of both to do nothing..
[22:14] <swebo> and annotate shows only the lines in the current version?
[22:15] <fullermd> 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] <fullermd> 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] <swebo> ah, ok.. now i got what you were saying ;-)
[22:16] <fullermd> If you were doing that, it would probably be easier to go from diffs of each revision than annotating each file/revision.
[22:17] <fullermd> Well, a little anyway.  Certainly a lot less redundant bzr churning at least.
[22:17] <fullermd> 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] <mgz> just hack something together with bzr annotate and wc, it's a dumb requirement that doesn't need a perfect solution
[22:22] <fullermd> Hush, you.  Writing a perfect solution would be WAY more fun than wasting time on classwork   :p
[22:23] <mgz> :)
[22:31] <swebo> well as i'm not studying computer science, it doesn't have to be perfect at all ;)
[22:51] <git__> what's the diff between bzr upload and bzr export ?
[22:52] <soren> git__: Couple of things..
[22:52] <soren> git__: export doesn't let you push to a remote location.
[22:53] <soren> 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] <soren> git__: upload does supports both of those things.
[22:54] <soren> 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] <git__> thanks soren, you are very thorough with your answer, really appreciated !!!
[22:55] <soren> git__: Sure.