| abentley | poolie: I'm up for a call. | 00:24 |
|---|---|---|
| poolie | hi | 00:28 |
| poolie | on skype or something, if you like? | 00:28 |
| abentley | poolie: http://code.aaronbentley.com/bzr/bzrrepo/288751-pack-deltas | 00:37 |
| jbalint | how do i handle "Contents conflict", the file has been renamed in the current tree | 00:52 |
| thumper | how do I change the format of a branch from BranchFormat7 to BranchFormat6? | 00:58 |
| jbalint | maybe bzr upgrade? | 01:00 |
| spiv | jbalint: see "bzr help conflicts" | 01:01 |
| spiv | jbalint: a contents conflict is when bzr sees conflicting changes to a non-text file. | 01:01 |
| awilkins | Or the addition of a file with the same path | 01:02 |
| jbalint | hrm, these shouldnt be nontext | 01:02 |
| awilkins | In two seperate branches | 01:02 |
| jbalint | one is .h, its the exact files taht are renamted | 01:02 |
| spiv | awilkins: Hmm, "bzr help conflicts" suggests that would reported differently. | 01:04 |
| spiv | Note that symlinks and directories count as non-text files... | 01:05 |
| awilkins | I've never seen a "path" conflict, only content ones | 01:05 |
| awilkins | And these are for ASCII text files | 01:06 |
| awilkins | Maybe it's a windows thing? | 01:06 |
| spiv | Maybe, I wouldn't know. | 01:06 |
| kingfishr | what is the shortest sequence of commands to give me the equivalent of hg addremove? | 01:47 |
| spiv | kingfishr: something like "bzr add; bzr commit" IIRC (commit will automatically remove missing files by default, I think). | 01:51 |
| kingfishr | oh really? | 01:52 |
| kingfishr | that's convenient | 01:52 |
| kingfishr | i wasn't aware of that | 01:52 |
| spiv | I think --strict will disable that behaviour. Try it out, it's easy to experiment : | 01:53 |
| spiv | :) | 01:53 |
| === ubott2 is now known as ubottu | ||
| poolie | jam, are you still around? did you do a patch towards bug 300177, i don't remember | 02:21 |
| ubottu | Launchpad bug 300177 in bzr "get_record_stream/ContentFactory should expose compression parents" [High,Confirmed] https://launchpad.net/bugs/300177 | 02:21 |
| synic | I want to write a clone of gitosis for bzr, I'm just wondering if anyone is already doing this (other than bzr_access)? | 02:38 |
| james_w | I had heard tell that gitosis may support bzr | 02:39 |
| james_w | or maybe I'm thinging of something else | 02:39 |
| synic | hrmm, not in it's current state | 02:40 |
| spiv | bzr_access is the closest I know if. | 02:42 |
| spiv | s/if/of/ | 02:42 |
| synic | ok, cool | 02:43 |
| vila | Gooood morning all | 05:22 |
| spiv | vila: good morning. | 05:26 |
| spiv | vila: you seem to be around early today :) | 05:26 |
| vila | spiv: no, check your clock :) | 05:26 |
| vila | kidding, I dropped my girlfriend to the airport :) | 05:26 |
| army | hi ,i have a problem with bzr-svn, | 05:31 |
| army | bzr 1.9 bzr-svn 0.4.15, check out http://www.prestashop.com/publicsvn ,error | 05:33 |
| === doko_ is now known as doko | ||
| kisielk_home | As a new user to bazaar, I have a few question about repositories. In order to use an sftp:// repository, does bazaar actually have to be installed on the host? | 08:18 |
| kisielk_home | or is it enough to have it just on the client? | 08:18 |
| luks | kisielk_home: no, it doesn't have to be on the server | 08:20 |
| luks | kisielk_home: only for bzr+ssh or bzr+http protocols | 08:21 |
| kisielk_home | nice | 08:21 |
| kisielk_home | yeah, I just want to keep some configuration files on my web server | 08:21 |
| kisielk_home | and sync them to the machines I use | 08:21 |
| kisielk_home | but it's shared hosting, so no bzr installed there | 08:21 |
| luks | should work fine | 08:21 |
| kisielk_home | cool | 08:22 |
| vila | jam: When you'll come online, have a look at the last comment in bzrlib.tests.test_log.TestShowlog.test_simple_log :-/ | 08:34 |
| === thekorn_ is now known as thekorn | ||
| === kiko-afk is now known as kiko | ||
| robsta | hi | 10:55 |
| robsta | what's the best changelog script with bzr, prepare-ChangeLog.pl seems not to handle it | 10:55 |
| === bac is now known as bac_afk | ||
| robsta | jelmer: thanks for the fresh bzr-svn deb on the ppa, i can now clone my svn repo and `bzr check' works | 11:54 |
| jelmer | robsta: n/p | 11:56 |
| jelmer | robsta: what's prepare-ChangeLog.pl exactly, is it GNOME-specific? | 11:57 |
| robsta | nothing, it doesn't do bzr at all | 11:57 |
| robsta | (my version at least) | 11:57 |
| jelmer | I think there was a plugin that could write GNU-like ChangeLog entries | 11:58 |
| robsta | interesting | 11:58 |
| robsta | i'm really only using the script to create commit messages | 11:58 |
| jelmer | ah, it creates commit messages from the changelog rather than the other way around? | 11:59 |
| jelmer | in that case, the plugin won't be of much use to you | 12:00 |
| robsta | i run prepare-ChangeLog.pl, then paste it when committing | 12:00 |
| robsta | the changelog is just a side-product of that | 12:00 |
| asabil | robsta: you probably want to use moap instead of prepare-ChangeLog.pl | 12:13 |
| asabil | I have a patched version of moap that produces the exact same output | 12:13 |
| robsta | asabil: with function names? | 12:13 |
| asabil | ah, no I don't think so :/ | 12:14 |
| robsta | :( | 12:15 |
| robsta | seems like maintainer.py doesn't to bzr either | 12:15 |
| asabil | well, I only used moap with Vala, so I don't know if it tries to extract function names for C code | 12:16 |
| robsta | heck, how hard can it be to hack prepare-ChangeLog.pl ... | 12:28 |
| === kiko is now known as kiko-fud | ||
| Sadr | Bazaar is mainly designed for code, correct? But, could it be also used for, say, model/asset revisions tied up with a web-based GUI? | 14:07 |
| === kiko-fud is now known as kiko-afk | ||
| Sadr | second try... any examples of Bazaar being used for *files* (e.g. a .blend or .max) ? | 15:04 |
| Sadr | we're looking into maybe using Bazaar as an advanced file manager for our open source website | 15:05 |
| jelmer | Sadr: hi | 15:05 |
| jelmer | Sadr: The obvious problem with binary files is merging - bazaar does line-based merging | 15:05 |
| jelmer | other than that, it should work fine | 15:05 |
| Sadr | I see | 15:07 |
| awilkins | Ok ; here's a talking point ; tags | 15:08 |
| awilkins | All tags are replicated between branches on a push, pull, branch, even if they are on dead revisions | 15:10 |
| awilkins | e.g. | 15:10 |
| awilkins | bzr init one ; cd one ; echo one > one ; bzr add ; bzr commit -m "One ; bzr tag ONE ; bzr uncommit --force ; bzr commit -m "Two" ; bzr tag TWO ; cd .. ; bzr branch one two ; cd two ; bzr tags | 15:11 |
| awilkins | Dang, missing a quote | 15:12 |
| jelmer | awilkins: I think it's intentional to keep those | 15:12 |
| awilkins | jelmer: But then you have a tag that marks a revision that potentially does not exist in the target branch / repo | 15:12 |
| awilkins | jelmer: Dead revisions are not branched to the other branch, what's the sense in identifying them. | 15:12 |
| awilkins | In my case, I then ran into tag conflicts with new revisions (the tags are being generated by a script for metadata purposes) | 15:14 |
| Odd_Bloke | awilkins: 'bzr branch -rtag:dead-revision <original branch>'? | 15:14 |
| awilkins | Odd_Bloke: 'spose... :-) it does seem rather marginal | 15:15 |
| Odd_Bloke | awilkins: Sure, but if the tag disappears, you don't know that you haven't got all of the revisions that were tagged. | 15:16 |
| Odd_Bloke | And presumably the tag still existed for a reason. | 15:16 |
| awilkins | I shouldn't run into it again, my script now overwrites the tags ; and people shouldn't push before they are sure they are not going to uncommit. | 15:16 |
| awilkins | The tag exists to identify live revisions that represent places to do a fancy diff report | 15:17 |
| jelmer | wow, has_revision() really profits from the 1.9 formats.. | 15:17 |
| vila | jam: ping | 15:20 |
| derekS | hi all. just a quick question. what is the difference between committing to a local branch and pushing to a local folder? | 15:25 |
| derekS | not used to this dvcs :) | 15:26 |
| Odd_Bloke | derekS: You push commits. | 15:26 |
| Odd_Bloke | You commit changes. | 15:26 |
| Odd_Bloke | So push recreates your branch wherever you push to. | 15:27 |
| Odd_Bloke | Your branch doesn't include anything that hasn't been committed. | 15:27 |
| derekS | Odd_Bloke: so pushing a commit just merges it upstream? | 15:27 |
| awilkins | derekS: pushing only works if no merge is required :-) | 15:28 |
| Odd_Bloke | Nope, merging is a different concept. | 15:28 |
| derekS | so, pushing just puts my branch upstream? | 15:28 |
| derekS | so it copies my branch to the one i pushed to? | 15:28 |
| Odd_Bloke | What do you mean by 'upstream'? Pushing just puts your branch wherever you're pushing to. | 15:28 |
| awilkins | pushing sends your revisions to the target branch, if it has no revisions that are children of the common ancestor you share | 15:29 |
| derekS | hmm gotcha | 15:29 |
| derekS | sorry, i am gjust trying to figure out how i can switch my svn to bzr | 15:29 |
| derekS | the owrkflow part | 15:29 |
| derekS | i use svn right now as a pseudo document management system :) | 15:29 |
| derekS | for my personal files | 15:30 |
| awilkins | Heh, I found it liberated me from the workflow of svn :) | 15:30 |
| awilkins | No having-to-be-in-the-office or on-the-vpn | 15:30 |
| awilkins | Started off with SVK and when that had a major oops, moved onto bazaar | 15:30 |
| derekS | awilkins: yeah :) i like it | 15:30 |
| derekS | just trying to create my workflow | 15:31 |
| awilkins | That reminds me... I was going to have a crack at bzr-svn 0.5 on this monster repo to see how it does compared to 0.4 | 15:32 |
| * awilkins gets busy downloading stuff | 15:32 | |
| derekS | have fun! | 15:32 |
| === abadger19991 is now known as abagder1999 | ||
| === abagder1999 is now known as abadger19991 | ||
| === abadger19991 is now known as abadger1999 | ||
| === sdboyer is now known as sdboyer|class | ||
| pickscrape | Is it possible to create a patch using bzr send which is against an earlier revision on the branch without having to bzr branch -r that revision out temporarily? | 17:29 |
| pickscrape | e.g. I have a branch that I submitted at r50, and I commit 5 more changes (to r51) and want to submit those 5 changes as a new patch but not including the work up to r50. | 17:30 |
| LeoNerd | Presumablly -r50..51 ? | 17:30 |
| pickscrape | Doesn't defining a range like that create a cherry pick? | 17:31 |
| LeoNerd | Yes. But that's what you're doing here | 17:31 |
| pickscrape | OK, asking my colleague to try that. Thanks :) | 17:32 |
| pickscrape | Related question, but when using a loom is there a simple way to say "send this thread" or does that also require looking at log and specifying the relevant revisions? | 17:33 |
| jam | vila: pong, sorry about the delay | 17:38 |
| vila | jam: np, just a quick chat about but #300055 | 17:39 |
| vila | jam: np, just a quick chat about bug #300055 | 17:39 |
| ubottu | Launchpad bug 300055 in bzr ""bzr log --forward FILE" crashes for revision range if first revision is not mainline" [Medium,In progress] https://launchpad.net/bugs/300055 | 17:39 |
| vila | gee ubottu, can't you see that I mixed up your nick and bug ? | 17:39 |
| vila | jam: So, as said in the bug comments, I commited 2 fixes already, cleaned up the tests (finding a semi-bogus one on the way) | 17:40 |
| vila | And I'm now to the point where I realized there are still problems lying around | 17:41 |
| jam | well, making things better than they are now is worth merging | 17:41 |
| jam | even if you don't have an absolute solution | 17:42 |
| vila | That was my feeling but I wanted to discuss a bit to clarify my mind, I want to send the submission with some explanations to start the discussion | 17:43 |
| vila | Roughly, we tend to enlarge the revision ranges to include the mainline revisions | 17:44 |
| vila | I think this is motivated by two facts: 1) that made the programming easier (wrong reason :), 2) we display dotted revnos *after* the mainline revisions they are merge into | 17:46 |
| vila | 2) does not play play well for several reasons | 17:46 |
| vila | a) it makes the code *harder* as soon as the revision ranges are not "complete" (as including the mainline revision and all its merged revisions) | 17:48 |
| synic | what is the equivalent of "bzr checkout" in bzrlib? WorkingTree doesn't have a 'checkout' method | 17:48 |
| vila | b) the display is ill-defined when the range is not complete | 17:49 |
| jam | synic: Branch.create_checkout, IIRC, you can look in 'builtins.py' for the 'cmd_checkout' class | 17:49 |
| synic | ok | 17:49 |
| vila | The root cause being that reverse_by_depth works in one direction only and this went unnoticed until now, so many cases are not covered | 17:50 |
| vila | err, scratch that | 17:50 |
| jam | so let's start at the beginning | 17:51 |
| vila | The root cause being that reverse_by_depth works in one direction only, this went unnoticed until now but it was used in several places ignoring that fact | 17:51 |
| jam | "we tend to enlarge the revision ranges to include the mainline revisions" | 17:51 |
| vila | ok | 17:51 |
| jam | we want to go from a revision in the ancestry | 17:51 |
| jam | and track where it was merged until we get down to mainline | 17:51 |
| jam | merge-sorted revisions have this information easily available | 17:51 |
| jam | reversed... not so much | 17:52 |
| jam | I couldn't actually work out an obvious answer once they have been reversed. | 17:52 |
| vila | I argue that we may not want to do that unconditionally | 17:52 |
| jam | vila: perhaps, but for now it was chosen as the best trade off | 17:53 |
| jam | between showing all cases where the change was merged into | 17:53 |
| jam | and showing none | 17:53 |
| jam | it is logically an optional thing | 17:53 |
| jam | but to make it *actually* optional | 17:53 |
| jam | requires updating the UI | 17:53 |
| jam | and passing the parameters across the stack | 17:53 |
| jam | which is generally non-trivial | 17:53 |
| jam | It most certainly *can* be done. It wasn't worth my time | 17:54 |
| jam | and I would argue it isn't worth your time *right now* | 17:54 |
| jam | changing log so that it doesn't have to access as much ancestry would be a better thing to work on | 17:54 |
| jam | and that may restructure the code anwyay | 17:54 |
| jam | anyway | 17:54 |
| vila | jam: sorry, phone, back in a few minutes | 17:55 |
| vila | jam: back | 17:56 |
| jam | np | 17:57 |
| vila | Ok, I see your point. Yet, the case reported, starting at a dotted revno and fixed as of today allows to avoid showing a bunch of revisions (~50 or 100) so there is some motivation to handle it to respect user request | 17:57 |
| vila | But, you're right, I may submit the actual fixes and just add a note that some more work may be needed, the fixes themselves provides a better solution but doesn't address all the cases either | 17:59 |
| vila | Oh, re-reading your comments, I don't argue that we must not include the mainline revs, just that we don't have to include them if they are outside the requested range, i.e. at start/end only. But doing so raises some problems in the way we display them: | 18:01 |
| vila | We can display hanging revisions (without their mainline) at start, but we can't to that at end, because there isn't a mainline rev to aggregate them there | 18:02 |
| jam | vila: I don't quite see how you can get a revision that is in the ancestry that never ends up merged to a mainline revision | 18:02 |
| jam | it... wouldn't be in your ancestry if that was the case | 18:03 |
| vila | So doing 'log x.n.m..y.p.q' and 'log x.n.m..y.p.q --forward' can't display the same revisions | 18:03 |
| vila | the revision *is* in the ancestry but the range *excludes* it | 18:03 |
| jam | well, we only do the projection to mainline revs if you are logging a file | 18:03 |
| === jdong_ is now known as jdong | ||
| vila | Look at lp:~/vila/bzr/300055-log-forward, bzrlib/tests/test_log.py TestGetViewRevisions.test_file_id_for_range for an example or try the reported case with my fix | 18:05 |
| vila | in the reported case, the first required revision is 1616.70.54 which was merged in 1627 | 18:06 |
| vila | Yet, with my fix and --forward, we don't display 1627 | 18:06 |
| vila | but we display it *without* --forward | 18:07 |
| vila | A bit hard to explain :-/ | 18:07 |
| jam | no, I understand what you mean | 18:08 |
| jam | IMO being consistent would be nice | 18:08 |
| jam | and I would probably go for "always show it" | 18:08 |
| jam | because I think it would be easier | 18:09 |
| vila | :-) | 18:09 |
| vila | Right, now, we understand each other I think :-) Easier for the dev may not be what the user is wanting, but the user may want other things first ! Does that summarize the discussion ? | 18:11 |
| jam | vila: yep | 18:21 |
| jam | Getting a "correct if suboptimal" result for log | 18:21 |
| jam | is the most important | 18:21 |
| jam | and getting other stuff done is better than optimizing the rest of log | 18:21 |
| vila | ok. I call it a day then (started a 6h30 this morning :) | 18:23 |
| vila | have a nice week-end ! | 18:23 |
| LarstiQ | vila: you too! | 18:25 |
| jam | you too vila | 18:37 |
| === sdboyer|class is now known as sdboyer | ||
| jam | does anyone know if LP can handle 1.9 format branches yet? | 20:21 |
| beuno | jam, IIRC, it only has up to 1.8 | 20:22 |
| beuno | actually, it's on 1.7.1rc1 | 20:23 |
| beuno | so... only if used through sftp maybe? | 20:23 |
| beuno | I don't know how picky the smart server is about formats it doesn't know | 20:24 |
| jam | I don't think it can mirror branches from sftp => http side if it doesn't understand them | 20:24 |
| jam | and I don't think it can mirror a branch on my webserver if I upgraded it to 1.9 either | 20:25 |
| beuno | right, the puller will probably b0rk | 20:25 |
| jam | you would be able to *push* to bzr+ssh the first time | 20:25 |
| jam | and then future access will likely give "Unknown Format" errors | 20:25 |
| Peng_ | Yeah, the puller can't mirror from 1.9 branches. | 20:25 |
| Peng_ | (on external web servers, I mean) | 20:25 |
| jam | Perhaps if you used nosmart+bzr+ssh or some other crazy workaround like that | 20:25 |
| jam | which I suppose isn't terrible considering if you were using 1.9 it would trigger the auto-stack from LP, and we know that is a little bit buggy right now | 20:27 |
| jam | I'm trying to finish up Martin's fix and get it merged. | 20:27 |
| beuno | oh, that would be great | 20:29 |
| beuno | then we just push everyone to use nightly | 20:29 |
| jam | well, I think Martin wants to make sure things are going smooth | 20:36 |
| jam | and then have it all in 1.10rc1 which will be on Friday | 20:36 |
| jam | (1 week) | 20:36 |
| synic | how can I create a hook that only runs when a certain branch is pushed to? | 21:34 |
| freewilly1 | Client-side? Use post_push. For server-side, you'll have to use post_change_branch_tip | 21:45 |
| freewilly1 | I bet there's a way to check which branch is being operated on, but I don't know enough to answer that | 21:47 |
| === freewilly1 is now known as kumi1 | ||
| synic | ok, yeah, that's what I'm looking for is which branch it is | 21:48 |
| === jfroy|work is now known as jfroy | ||
| === jfroy is now known as jfroy|work | ||
| synic | jam: ping | 23:29 |
| jfroy|work | Anyone here has setup some manner of automated Subversion Bazaar mirroring solution? | 23:37 |
| jfroy|work | Curious about people's experience, solutions, gotchas, and so on. | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!