| === knitt1 is now known as knittl | ||
| === oubiwann is now known as oubiwann-holiday | ||
| === oubiwann-holiday is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| === oubiwann is now known as oubiwann_ | ||
| === oubiwann_ is now known as oubiwann | ||
| daveb_ | hey | 14:27 |
|---|---|---|
| daveb_ | has anyone done anything with inotify and bzr to have an automatic push system? | 14:28 |
| glyph | daveb_: bzr already has automatic pushing, I think you mean automatic committing? | 14:36 |
| thorwil | hi! i have one development branch and a packaging branch on lp. for the first rev of the packaging branch, the reference to the devel branch is clear. | 14:51 |
| thorwil | but now, several devel revs later, easiest would be to copy the files i need to the packaging branch. but is there a way to associate the packaging rev with a devel rev, then? | 14:51 |
| daveb_ | glyph: yes, thats what i mean | 15:15 |
| daveb_ | has anyone done anything with inotify and bzr to have automatic commiting? | 15:25 |
| mgedmin | I wonder if you could use SparkleShare for that (if you convinced it to use bzr as a backed instead of git) | 15:30 |
| jam1 | morning #bzr | 15:32 |
| === jam1 is now known as jam | ||
| === jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | | 2.3b4 is officially out ! (rm vila) | ||
| jam | hey vila, are you still around? Just wanted to say happy new year | 15:38 |
| vila | jam: yeah ! Happy new year to you too ! | 15:55 |
| === beuno is now known as beuno-lunch | ||
| daveb_ | mgedmin: would there be an advantage to using git? | 16:13 |
| mgedmin | well, you could use unmodified sparkleshare, if you used git, I suppose | 16:14 |
| mgedmin | but I don't know if it fits your usecase | 16:14 |
| mgedmin | or if it's sufficiently functional in its current beta incarnation | 16:14 |
| === Ursinha is now known as Ursinha-lunch | ||
| daveb_ | well, i want the some of the advantages of a VCS, but I really want something that is so simple that people dont have to think about using it, maybe implemented in a filesystem or something... high availability (offline access) is importaint. I was thinking of using some sort of wrapper for bzr, so that when ever anyone change something on their checkout, it would automatically commit it so it would be available... | 16:19 |
| mgedmin | sounds like you're looking for something like Dropbox (or Ubuntu One) | 16:22 |
| daveb_ | mgedmin: we like dropbox, we just want to be able to host it | 16:22 |
| daveb_ | and, well, versioning would be nice | 16:23 |
| * mgedmin nods | 16:23 | |
| mgedmin | sounds like SparkleShare is exactly that then | 16:23 |
| mgedmin | if you're not allergic to c#/mono/git | 16:24 |
| mgedmin | or software that's in beta | 16:24 |
| daveb_ | yea, thanks for pointing me to it | 16:24 |
| * mgedmin is keeping an eye on it, but hasn't tried it yet | 16:24 | |
| daveb_ | it looks promising | 16:24 |
| daveb_ | they say windows support is comming soon | 16:24 |
| chx | i am running 2.3b4 and i tried bzr resolve --take-other modules/comment/comment.test but it says Text conflict in modules/comment/comment.test | 16:29 |
| vila | chx: I think it's part of the upcoming 2.3b5, let me check | 16:32 |
| vila | chx: yup, 2.3b5 | 16:34 |
| vila | chx: I don't remember the details, but the behaviour in b4 is... blurry... | 16:35 |
| vila | chx: but you can achieve the same effect with: cp c.t.OTHER c.t ; bzr resolve c.t | 16:36 |
| chx | sure | 16:42 |
| === beuno-lunch is now known as beuno | ||
| === Ursinha-lunch is now known as Ursinha | ||
| zyga | hi | 17:45 |
| zyga | should bzr be installable via pip on win32? | 17:45 |
| zyga | I installed visual studio express 2008 | 17:45 |
| zyga | but the install script fails on ValueError in distuitls msvc9compiler.py | 17:46 |
| phil` | Anyone willing and able to help fix a messed-up install of bzr on debian? | 17:48 |
| zyga | phil`, how did you install? | 17:52 |
| phil` | sudo apt-get install bzr bzrtools | 18:04 |
| phil` | Here's the output: | 18:04 |
| phil` | The following packages have unmet dependencies: | 18:04 |
| phil` | bzr : Depends: python (< 2.6) but 2.6.6-3+squeeze4 is to be installed | 18:04 |
| phil` | 18:04 | |
| phil` | Had it installed and working for years | 18:04 |
| phil` | A while back, started getting 'packages held back' when doing apt-get update | 18:05 |
| phil` | Decided today to uninstall and re-install, but no go, same 'unmet deps' msg | 18:06 |
| phil` | AFAICT I have up-to-date python2.6 and python2.5 installed | 18:09 |
| maxb | phil`: This would tend to suggest the bzr package being seen is not the correct one for your distribution | 18:11 |
| maxb | Please pastebin your /etc/apt/sources.list | 18:11 |
| maxb | also the output of 'apt-cache policy bzr' | 18:12 |
| maxb | also say whether you have any files in /etc/apt/sources.list.d/ | 18:12 |
| phil` | newb: ?pastebin? (sorry) | 18:12 |
| maxb | A website for sharing text more conveniently than long pastes directly in the channel | 18:13 |
| maxb | e.g. http://paste.ubuntu.com | 18:13 |
| phil` | Gotcha | 18:13 |
| phil` | apt-cache policy: http://paste.ubuntu.com/549918/ | 18:14 |
| phil` | sources.list: http://paste.ubuntu.com/549921/ | 18:16 |
| phil` | sources.list.d is empty | 18:16 |
| maxb | ah | 18:18 |
| maxb | You seem to be using Ubuntu hardy packages on your Debian system | 18:19 |
| phil` | D'oh | 18:19 |
| maxb | For a Debian squeeze machine, I'd say you have a better chance using Ubuntu lucid packages thatn Ubuntu hardy | 18:20 |
| phil` | Installing now! Thank you maxb, you're a hero. | 18:25 |
| maxb | It's a shame we don't have a better solution for Debian, but setting up a buildd system isn't easy | 18:31 |
| phil` | I hear that | 18:31 |
| phil` | All good now! | 18:32 |
| notmyname | now that I've been working on a project for a while, I've got lots of directories (including "trunk") in my parent directory (the one where I ran bzr init-repo). how can I tell which ones have been merged into trunk? | 18:50 |
| beuno | notmyname, bzr missing ..//otherbranch | 18:51 |
| beuno | that;s ../otherbranch | 18:51 |
| beuno | or the path to it | 18:51 |
| notmyname | so I go to "trunk", run "bzr missing /path/to/otherbranch" and what do I see if it's been merged (or hasn't been merged)? a nice message? nothing? | 18:52 |
| beuno | if nothin is missing, then you get nothing | 18:55 |
| beuno | id something is, it tells you which revisions | 18:55 |
| maxb | You probably want 'bzr missing --mine-only ../trunk' or 'bzr missing --theirs-only ../otherbranch' | 18:58 |
| notmyname | maxb: thanks. I was getting lots of output without those switches | 19:00 |
| notmyname | beuno: maxb: thanks for the help | 19:00 |
| glyph | so I'm reading the DaggyFixes page | 20:52 |
| glyph | and I think I finally managed to understand it | 20:52 |
| glyph | but there is a use-case it doesn't cover: what if I want to use a testing feature that was introduced some time after the bug was introduced in order to test the fix? | 20:53 |
| jam | glyph: then you use a later version of the branch | 20:56 |
| jam | the point of doing it early, is so it is easier to apply the fix in lots of scenarios | 20:56 |
| jam | if you need new test infrastructure, then that no longer applies | 20:57 |
| jam | but it also clearly means that you won't be able to easily apply the new bugfix to old releases | 20:57 |
| glyph | I guess the gist of daggyfixes is actually just 'fix it in the old branch first' | 20:59 |
| jam | glyph: that is the basic idea | 20:59 |
| jam | if that isn't practical | 20:59 |
| jam | then do whatever makes the most sense | 20:59 |
| jam | you also can layer the fix | 20:59 |
| jam | using looms/etc | 21:00 |
| jam | so you have a branch where you fix it | 21:00 |
| jam | which then you merge into a newer branch that has the tests. | 21:00 |
| jam | though that runs into "is it really fixed in the original branch? I don't have a test for it" | 21:00 |
| glyph | jam: In this case, the question was really about test infrastructure introduced on the older branch, but after the fix | 21:15 |
| glyph | so the answer is really 'okay, just start after the test infrastructure was introduced then' | 21:16 |
| glyph | there's another class of question though, which is 'what if the project policy is always "fix on the new branch first, then backport fixes"' | 21:16 |
| glyph | and there are a bunch of different formulations of that, but from what I can tell it's 'do a merge with a -r argument and then don't forget that you did that because if you do it again it will look awful and have tons of conflicts' | 21:17 |
| === seiflotfy_ is now known as help | ||
| === help is now known as Guest41209 | ||
| === Guest41209 is now known as seiflotfy | ||
| === spm` is now known as spm | ||
| === Meths_ is now known as Meths | ||
| === rockstar is now known as rockstar` | ||
| === rockstar` is now known as rockstar | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!