| poolie | wow, bzr-colo is really nince | 00:12 |
|---|---|---|
| poolie | *nice | 00:13 |
| === dOxxx is now known as dOxxx_away | ||
| cheater99 | hi guys | 08:11 |
| poolie | hi | 09:12 |
| === ddaa1 is now known as ddaa | ||
| 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:38 |
| sinasalek1 | Anyone? | 11:40 |
| Kamping_Kaiser | lock? | 11:43 |
| sinasalek1 | yup | 11:45 |
| sinasalek1 | Kamping_Kaiser: why i'm unable to find any documentation regarding to this? | 11:45 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 | |
| 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:52 |
| 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:53 |
| ddaa | I kindaaaa see it now | 11:54 |
| ddaa | it's a bit like checkouts, only more so. | 11:54 |
| 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:55 |
| ddaa | first, it would require a new *branch* format | 11:57 |
| ddaa | since it would be non-versioned branch-local data. | 11:57 |
| ddaa | then a new tree format, to translate the lock into fs permissions | 11:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| ddaa | like commit, push, pull, etc. | 12:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| ddaa | now, another riddle | 12:10 |
| ddaa | after using "bzr branch", we can't do the locking anymore | 12:10 |
| 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:11 |
| 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:12 |
| ddaa | gaaah! | 12:13 |
| ddaa | vila: did anybody answer that one, yet? | 12:13 |
| ddaa | now, there's another desirable feature | 12:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 | |
| ddaa | actually, the "lock location" info should be unversioned branch data too | 12:25 |
| ddaa | and the "assign lock to another branch" is the same mechanism that should be used when locking to a heavy checkout. | 12:26 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| 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:40 |
| maxb | cherrypick merge? | 18:46 |
| JoshBrown | maxb: Thanks, I'll try it. | 19:06 |
| 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:41 |
| mgz | 33..36 surely. | 19:42 |
| mgz | you want his changes included, not to back them out after they've already been committed | 19:43 |
| git__ | hey, does "bzr export ftp://[username]:[password]@ftp.domain.com work? | 19:50 |
| 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:52 |
| mgz | do `bzr revert` then try again with --preview added? | 19:55 |
| git__ | i accidently delete everything in my working tree ... .bzr directory is still there, how do I get my working tree back? | 19:57 |
| 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:58 |
| 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 |
| === jam1 is now known as jam | ||
| mgz | `bzr update -r 6` | 19:59 |
| mgz | sure jam, I'll take a look. | 19:59 |
| mgz | ...when launchpad updates the diff, because I'm lazy | 20:01 |
| mgz | all looks reasonable, I'll run the tests locally as well. | 20:10 |
| 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:11 |
| mgz | +is fixed | 20:14 |
| mgz | bt.test_selftest.TestSubunitLogDetails.test_success_has_no_log fails here, it does contain the log. | 20:16 |
| mgz | you appear to have just not changed addSuccess | 20:20 |
| jam | mgz: I just didn't commit before my last push :) | 20:31 |
| mgz | :D | 20:31 |
| 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:33 |
| mgz | okay, that's more like it. | 20:35 |
| 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:36 |
| jam | the --subunit stack is *quite* different from our regular stack | 20:37 |
| jam | subunit doesn't inherit from testtools, for example | 20:37 |
| mgz | yep, it's a bit of a pain | 20:38 |
| 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:45 |
| 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:46 |
| 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:47 |
| mgz | `bzr revert ./debian` | 20:48 |
| mgz | (or whatever) | 20:48 |
| mgz | jam: have put a comment in the mp, don't know if you want to tackle the annoying merge now | 21:01 |
| jam | mgz: you mean submitting it? or what do you mean by 'annoying merge'? | 21:02 |
| mgz | yup, that. there have just been a few selftest changes lately, so there's always a conflict | 21:03 |
| jam | thanks for the heads up | 21:04 |
| jam | *glee* 2 conflicts | 21:04 |
| jam | mgz: and yeah, I had tried to do some of it using TextTestResult or whatever, and it was a bit... joyless | 21:05 |
| 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:06 |
| 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:08 |
| 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]) | 21:09 |
| === BasicPRO is now known as BasicOSX | ||
| swebo | hi | 22:05 |
| swebo | i want to find out how many lines each developer on a project has written. | 22:05 |
| 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:06 |
| fullermd | What a bizarre requirement... do you mean lines written total over history, or just lines in the current version? | 22:08 |
| fullermd | If it's just the latter, you could figure it from annotate pretty easy. | 22:09 |
| swebo | i think it's over the total history | 22:11 |
| 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:12 |
| swebo | well... i don't think it's a fair requirement, either ... | 22:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| mgz | just hack something together with bzr annotate and wc, it's a dumb requirement that doesn't need a perfect solution | 22:21 |
| fullermd | Hush, you. Writing a perfect solution would be WAY more fun than wasting time on classwork :p | 22:22 |
| mgz | :) | 22:23 |
| swebo | well as i'm not studying computer science, it doesn't have to be perfect at all ;) | 22:31 |
| git__ | what's the diff between bzr upload and bzr export ? | 22:51 |
| soren | git__: Couple of things.. | 22:52 |
| soren | git__: export doesn't let you push to a remote location. | 22:52 |
| 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:53 |
| 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:54 |
| git__ | thanks soren, you are very thorough with your answer, really appreciated !!! | 22:55 |
| soren | git__: Sure. | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!