| spiv | abentley: it looks like bundlebuggy's mail queue is growing without any new mail getting processed? http://bundlebuggy.aaronbentley.com/mail | 01:58 |
|---|---|---|
| === Spaz is now known as IchangedMyNickKi | ||
| === IchangedMyNickKi is now known as Spaz | ||
| abentley | spiv: fixed. | 03:55 |
| === RAOF_ is now known as RAOF | ||
| ToyKeeper | Hmm... I could have sworn there was a "--date" option for commit. | 07:24 |
| ToyKeeper | Looks like this will be as fun as setting the mtime on a symlink. | 07:34 |
| === jszakmeister|awa is now known as jszakmeister | ||
| === jszakmeister is now known as jszakmeister|awa | ||
| Enisseo | hello everyone! | 12:37 |
| Enisseo | I have a problem Google could not solve | 12:40 |
| Enisseo | does anyone ever tried to post/publish a bzr directory (sub directory of a branch) to a ftp server? | 12:41 |
| Enisseo | did* try* | 12:41 |
| CaMason | I was wondering.. say somebody committed a huge file, would it be possible to remove that file from the repo? | 12:41 |
| CaMason | I know that's near impossible with svn | 12:41 |
| Enisseo | maybe using bzr remove YOUR_FILE --force | 12:42 |
| Enisseo | CaMason: (never done that, but I would say it is technically possible, so maybe this "--force" option would do the trick, or a plugin) | 12:43 |
| CaMason | Enisseo: ok. I work with large flash / photoshop files quite often, and sometimes my designers can input a 400MB FLV file by accident. It would be great to be able to remove that to keep the repo size to a minimum | 12:45 |
| Enisseo | CaMason: if you do not want any .flv (or .psd) file to be committed, you can use the bzr ignore command | 12:46 |
| Enisseo | CaMason: but if you only need to limit the size of committed files, I don't know (plugin? configuration file?) | 12:47 |
| CaMason | Enisseo: It's not an exact science, as we DO need to add certain FLVs and PSDs of varying sized. It's things like placeholder/test items that were accidently placed in, that are of the wrong size | 12:48 |
| CaMason | usually the FLVs are embedded within the .fla files when testing, and these are sometimes accidently added | 12:48 |
| Enisseo | CaMason: if you can't find a "pattern" (subdirectory, extension, file size...) the files you do not want to add (or want to add) follow, the filter can not be made | 12:52 |
| Enisseo | CaMason: anyway, the bzr ignore command prevent - I think - adding files accidentally, but you still can add them if you do it explicitly | 12:53 |
| Enisseo | CaMason: for example, to prevent committing files with huge size (psd, flv), you set a ignore rule on .flv and .psd files | 12:54 |
| Enisseo | CaMason: but if you need to add some .psd or .flv files, you can still commit them | 12:55 |
| Enisseo | CaMason: this will work fine if you don't often need to commit PSD and FLV | 12:56 |
| Enisseo | (I'm not sure you can add files that match an ignore rule, but tests will tell you) | 12:58 |
| CaMason | Enisseo: sure, I understand you. But that wont help for my current workflow :) | 12:59 |
| CaMason | It's not a problem for me atm.. I'll read up about it another time. Thank you | 12:59 |
| Enisseo | CaMason: sorry I could not help you... maybe someone will, another day ;) | 13:00 |
| hmeland | "bzr add foo" will add foo, regardless of whether it matches an ignore rule or not. "bzr commit" will commit all added files, regardless of ignore rules. | 13:01 |
| Enisseo | thank you :) | 13:01 |
| Enisseo | My problem: I want to publish files of my branch to a ftp directory | 13:02 |
| hmeland | To remove files from history, you'd have to "rebuild" that history, while omitting the parts that you don't want. Bazaar doesn't have any built-in support for such operations. | 13:02 |
| hmeland | The "rebase" plugin is somewhat handy, though. | 13:02 |
| CaMason | hmeland: ok, nice :) I'll read up about it later on | 13:02 |
| Enisseo | The files are mostly PHP files, so I want bzr to act like a "website publisher" | 13:03 |
| Enisseo | Is this possible? | 13:03 |
| CaMason | Enisseo: http://bazaar-vcs.org/BazaarForWebDevs | 13:03 |
| hmeland | Enisseo: AFAIK, bzr works on the full tree; if you want to publish just a subtree, you're free to do so using other mirroring tools. | 13:03 |
| hmeland | Depending on what you mean by "publish", I guess... | 13:03 |
| Enisseo | I mean "copy files", not publishing a branch | 13:04 |
| Enisseo | In fact, I could do so "manually" by uploading an exported directory (export) of my branch | 13:04 |
| hmeland | Ok, then what I said above stands -- I'm not aware of anything in bzr that will help you with that publishing operation. | 13:05 |
| Enisseo | but I thought bzr would do that, only committing changed files | 13:05 |
| hmeland | Uhm, are you saying that you want to _automate_ publishing of that subtree whenever you commit? | 13:06 |
| Enisseo | no | 13:06 |
| Enisseo | Well, my workflow would be: | 13:06 |
| hmeland | Then you've lost me. :-) | 13:06 |
| Enisseo | 1. I commit files locally | 13:07 |
| Enisseo | 2. I finish adding features and fixing bugs so I could release a new version of my project | 13:07 |
| Enisseo | 3. => I "push/publish" the project into a prototype directory on my ftp server | 13:08 |
| Enisseo | 4. I fix last bugs that appear while testing the prototype | 13:08 |
| Enisseo | 5. => I "push/publish" the project into the production directory on the ftp server | 13:09 |
| Enisseo | 6. I tag the branch | 13:09 |
| Enisseo | the push/publish operation is manually "launched", but yes, indeed, I want bzr to automatically copy files that have changed between two publishing operations | 13:10 |
| bob2 | bzr-upload plugin | 13:11 |
| Enisseo | bob2: the name sounds nice :) | 13:11 |
| AfC | Yeah, you want the upload plugin | 13:16 |
| AfC | (orthogonally, do you *really* need to tag every time you publish?) | 13:17 |
| Enisseo | AfC: Hmmm... no | 13:18 |
| Enisseo | AfC: But what do you think is wrong with that | 13:18 |
| Enisseo | ? | 13:18 |
| AfC | Manageability | 13:18 |
| AfC | Enisseo: if you have several thousand tags it gets out of control | 13:19 |
| Enisseo | AfC: I do not want to tag every commit I made, only when I publish what I think is a new version | 13:19 |
| Enisseo | 0.1, 0.2, 1.1, 1.2... | 13:19 |
| bob2 | why bother? | 13:19 |
| AfC | Enisseo: and there may be scaling problems with hundreds of thousands of tags, I can't remember if that was addressed; it strikes me as the sort of thing that isn't really wise because it's going to be high O() | 13:20 |
| bob2 | just have a branch where each commit is a "publish" state | 13:20 |
| bob2 | all done | 13:20 |
| AfC | Enisseo: if you're just doing "versions" then that's fine, of course | 13:20 |
| AfC | Enisseo: I've seen people do an automated tag with a date string or some other nonsense, and then complain that the 14,000 tags they have are in the way. | 13:20 |
| AfC | bob2: well, if the history is linear that won't quite cut it | 13:21 |
| AfC | a merge isn't necessarily a prerequisite to Enisseo publishing. | 13:21 |
| AfC | but that saidm | 13:21 |
| AfC | said, | 13:21 |
| AfC | for people that really are desperate to have huge numbers of "tags", an alternative is | 13:22 |
| AfC | to just make an empty (no changes) commit with a commit message indicating $whatever. | 13:22 |
| AfC | THAT will scale just fine, of course. | 13:22 |
| Enisseo | what's the difference between tagging and branching with bazaar? | 13:23 |
| AfC | er | 13:24 |
| bob2 | mostly unrelated | 13:24 |
| bob2 | branch is a, well, branch, tag is just a label pointing at a particular commit on a branch | 13:24 |
| Enisseo | I thought a tag in bazaar was just a branch | 13:24 |
| bob2 | no | 13:25 |
| Enisseo | well, a named branch | 13:25 |
| AfC | no | 13:25 |
| Enisseo | ok | 13:25 |
| bob2 | svn is the only system like that, afaik | 13:25 |
| AfC | {sigh}, Subversion screwing up the name space strikes again | 13:25 |
| AfC | Enisseo: you can take a branch from any revision | 13:25 |
| Enisseo | I must have read that from svn, indeed | 13:25 |
| AfC | Enisseo: there are many ways to _identify_ revisions | 13:26 |
| AfC | Enisseo: tags are one of them. | 13:26 |
| AfC | (dates are another, etc) | 13:26 |
| AfC | I commonly do stuff like | 13:26 |
| AfC | $ bzr diff -r tag:v4.0.9 | 13:27 |
| Enisseo | so, if a tag is a label of a commit, many tags are just hard to manage, but it does not affect performances, does it? | 13:27 |
| AfC | to find out what I've changed from the last release | 13:27 |
| AfC | another *really* useful one is | 13:27 |
| AfC | $ bzr diff -r ancestor:../mainline | 13:27 |
| AfC | to see what is different about this branch (from a contributor, say) without worrying about what has moved on in 'mainline' in the mean time. | 13:28 |
| Enisseo | the "bzr diff -r tag:v4.0.9" command is what I have in mind | 13:29 |
| AfC | Enisseo: sure... but if you're only doing one or two revisions per release, and *frequent* releases, then I imagine you can see the utility dropping. | 13:31 |
| AfC | on the other hand if you don't do that many "releases" then you're all fine. | 13:31 |
| AfC | Enisseo: hard to manage (lots of tags), definitely (where lots >>> 100) | 13:32 |
| AfC | Enisseo: I can't say off hand what the performance impact is | 13:32 |
| Enisseo | ok, thanks for the advice ;) | 13:32 |
| AfC | I have a nagging feeling that someone was complaining about it, but I also recall they had like 100,000 tags | 13:32 |
| AfC | and were upset that bzr log was slow :) | 13:33 |
| AfC | if you're not already at hundreds of thousands of revisions, and gigabytes of repository, and tens of thousands of tags, I doubt you'll notice any performance problem. | 13:34 |
| mathrick | jelmer: hmm, why does bzr init in a directory below an svn checkout (but not versioned itself) invoke bzr-svn? | 15:17 |
| jelmer | mathrick, what version of bzr/bzr-svn ? | 15:17 |
| mathrick | jelmer: how do I check bzr-svn version? | 15:19 |
| mathrick | (it's not my copy y'see) | 15:19 |
| jelmer | mathrick, if you know the bzr version, that should be sufficient | 15:19 |
| mathrick | ok, it's 1.9 | 15:19 |
| mathrick | jelmer: btw, it seems to segfault on bzr init after upgrading to (python-)subversion 1.5.1 (from 1.4.6) | 15:21 |
| jelmer | mathrick, so you have a svn-versioned directory and one of the children paths has a .bzr directory? | 15:22 |
| mathrick | jelmer: no, I have a svn-versioned directory, and it has a non-versioned subdir that I (or my friend, actually) wants to init as a bzr repo | 15:23 |
| jelmer | mathrick, in that case, this is expected behaviour | 15:23 |
| mathrick | he doesn't care about the svn-versionedness of the parent | 15:23 |
| mathrick | jelmer: what purpose does it serve? | 15:24 |
| mathrick | and, how can I disable it? | 15:24 |
| jelmer | mathrick, sorry, forget that | 15:25 |
| jelmer | mathrick, I can't reproduce this | 15:25 |
| mathrick | jelmer: hmm | 15:25 |
| mathrick | jelmer: I'll try to get a reproducible example for you, sec | 15:27 |
| mathrick | jelmer: okay, I have a minimal dir structure that segfaults for me as well | 15:35 |
| mathrick | (bzr 1.6.1 / svn 1.5.1) | 15:35 |
| jelmer | mathrick, Have you tried 1.9 ? Several things have changed since then | 15:35 |
| mathrick | jelmer: yes, said friend runs 1.9 | 15:35 |
| mathrick | jelmer: http://sei.meidokon.net/files/foo.tar.gz | 15:37 |
| mathrick | unpack it, go to foo/bar/, try to bzr init there | 15:37 |
| mathrick | it segfaults | 15:38 |
| jelmer | mathrick, works fine here | 15:38 |
| mathrick | in earlier svn (1.4.6), it'd say the subversion client is too old | 15:38 |
| mathrick | humm | 15:38 |
| mathrick | are you running ubuntu? | 15:38 |
| jelmer | no, debian | 15:38 |
| mathrick | then it seems like something is broken in ubuntu packages | 15:39 |
| mathrick | jelmer: is it invoking bzr-svn at all for you? | 15:39 |
| marcus-b | Hi, I upgraded from bzr 1.3 in Ubuntu 8.04 to bzr 1.6.1 in Ubuntu 8.10, and now I get weird upgrade notices and errors on upgrade: http://pastebin.com/m15418d7 What should I do? | 15:41 |
| jelmer | mathrick, no, it doesn't touch bzr-svn | 15:42 |
| jelmer | I'm running bzr 1.10 though, not 1.9 | 15:42 |
| beuno | marcus-b, try: bzr upgrade --rich-root-pack | 15:42 |
| marcus-b | thanks, that seems to work. was it a mistake to use rich-root? what's the recommended format for new repositories? | 15:44 |
| beuno | marcus-b, also remember to upgrade both your branches and your shared repository | 15:44 |
| beuno | why did you choose rich-root? | 15:45 |
| marcus-b | I don't remember. I think I just chose the latest/greatest at the time | 15:45 |
| marcus-b | I want to go with the masses, no special requirements | 15:45 |
| beuno | jelmer, there's no way to go rich-root -> packs, is there? | 15:46 |
| jelmer | beuno: rich-root-pack | 15:46 |
| jelmer | beuno: there's no particular reason to go back from rich-root though | 15:46 |
| james_w | jelmer: you patch allows you to upgrade an svn checkout to be a bzr branch? | 15:46 |
| beuno | well, PITA, but yes :) | 15:46 |
| marcus-b | so the new cool kid on the block is packs? :) | 15:47 |
| jelmer | james_w, It's one of the required steps - I'm not sure whether bzr-svn's implementation of Converter works well enough yet | 15:47 |
| james_w | jelmer: madness :-) | 15:47 |
| beuno | marcus-b, actually, it's "1.9" format, but I'd say you take it a step at a time ;) | 15:48 |
| marcus-b | yeah, thanks ;) | 15:49 |
| marcus-b | so how about I go to 1.6.1-rich-root ? | 15:52 |
| jelmer | marcus-b, any reason for going with 1.6.1-rich-root rather than 1.9-rich-root? | 15:53 |
| marcus-b | well, ubuntu 8.10 ships with 1.6.1 | 15:53 |
| marcus-b | so, if there isn't a strong reason for a manual update or override... | 15:54 |
| marcus-b | ok, I am taking the ppa ubuntu repository, that's convenient enough for me | 16:15 |
| beuno | that's what I do :) | 16:16 |
| marcus-b | can I move away from rich-root? | 16:21 |
| === fta_ is now known as fta | ||
| bpierre | hi | 17:36 |
| gerel | hey all, short question, if I have changes in one file in this order, rev1 => rev2 => rev3, when I try to see changes between rev1 and rev3, all is fine, now when I try to see, whether the changes were made between rev1 and rev2 or rev2 and rev3, bzr outputs nothing!, does that make sense? | 18:19 |
| gerel | shouldn't there be a transitive property ? | 18:19 |
| gerel | well, solved, the thing is that "-rREV1 -rREV2" isn't the same as "-rREV1..REV2", I thought it was | 18:31 |
| Flimm | How can I tag a commit with a launchpad bug? | 20:16 |
| beuno | Flimm, maybe what you're looking for is: bzr ci --fixes=lp:1111 | 20:17 |
| beuno | or maybe it's --fixes lp:1111 | 20:18 |
| Flimm | Thanks bueno, you're always here when I need help! | 20:33 |
| CaMason_ | if I need to move my central branch to a different server, can I just copy/paste it? | 23:46 |
| bpierre | if it's a standalone branch, yes, it should work | 23:47 |
| CaMason_ | time to try, then :) | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!