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