[01:58] <spiv> abentley: it looks like bundlebuggy's mail queue is growing without any new mail getting processed?  http://bundlebuggy.aaronbentley.com/mail
[03:55] <abentley> spiv: fixed.
[07:24] <ToyKeeper> Hmm...   I could have sworn there was a "--date" option for commit.
[07:34] <ToyKeeper> Looks like this will be as fun as setting the mtime on a symlink.
[12:37] <Enisseo> hello everyone!
[12:40] <Enisseo> I have a problem Google could not solve
[12:41] <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:42] <Enisseo> maybe using bzr remove YOUR_FILE --force
[12:43] <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:45] <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:46] <Enisseo> CaMason: if you do not want any .flv (or .psd) file to be committed, you can use the bzr ignore command
[12:47] <Enisseo> CaMason: but if you only need to limit the size of committed files, I don't know (plugin? configuration file?)
[12:48] <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:52] <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:53] <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:54] <Enisseo> CaMason: for example, to prevent committing files with huge size (psd, flv), you set a ignore rule on .flv and .psd files
[12:55] <Enisseo> CaMason: but if you need to add some .psd or .flv files, you can still commit them
[12:56] <Enisseo> CaMason: this will work fine if you don't often need to commit PSD and FLV
[12:58] <Enisseo> (I'm not sure you can add files that match an ignore rule, but tests will tell you)
[12:59] <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
[13:00] <Enisseo> CaMason: sorry I could not help you... maybe someone will, another day ;)
[13:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <Enisseo> 5. => I "push/publish" the project into the production directory on the ftp server
[13:09] <Enisseo> 6. I tag the branch
[13:10] <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:11] <bob2> bzr-upload plugin
[13:11] <Enisseo> bob2: the name sounds nice :)
[13:16] <AfC> Yeah, you want the upload plugin
[13:17] <AfC> (orthogonally, do you *really* need to tag every time you publish?)
[13:18] <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:19] <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:20] <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:21] <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:22] <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:23] <Enisseo> what's the difference between tagging and branching with bazaar?
[13:24] <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:25] <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:26] <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:27] <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:28] <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:29] <Enisseo> the "bzr diff -r tag:v4.0.9" command is what I have in mind
[13:31] <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:32] <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:33] <AfC> and were upset that bzr log was slow :)
[13:34] <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.
[15:17] <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:19] <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:21] <mathrick> jelmer: btw, it seems to segfault on bzr init after upgrading to (python-)subversion 1.5.1 (from 1.4.6)
[15:22] <jelmer> mathrick, so you have a svn-versioned directory and one of the children paths has a .bzr directory?
[15:23] <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:24] <mathrick> jelmer: what purpose does it serve?
[15:24] <mathrick> and, how can I disable it?
[15:25] <jelmer> mathrick, sorry, forget that
[15:25] <jelmer> mathrick, I can't reproduce this
[15:25] <mathrick> jelmer: hmm
[15:27] <mathrick> jelmer: I'll try to get a reproducible example for you, sec
[15:35] <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:37] <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:38] <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:39] <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:41] <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:42] <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:44] <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:45] <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:46] <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:47] <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:48] <beuno> marcus-b, actually, it's "1.9" format, but I'd say you take it a step at a time  ;)
[15:49] <marcus-b> yeah, thanks ;)
[15:52] <marcus-b> so how about I go to 1.6.1-rich-root ?
[15:53] <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:54] <marcus-b> so, if there isn't a strong reason for a manual update or override...
[16:15] <marcus-b> ok, I am taking the ppa ubuntu repository, that's convenient enough for me
[16:16] <beuno> that's what I do  :)
[16:21] <marcus-b> can I move away from rich-root?
[17:36] <bpierre> hi
[18:19] <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:31] <gerel> well, solved, the thing is that "-rREV1 -rREV2" isn't the same as "-rREV1..REV2", I thought it was
[20:16] <Flimm> How can I tag a commit with a launchpad bug?
[20:17] <beuno> Flimm, maybe what you're looking for is: bzr ci --fixes=lp:1111
[20:18] <beuno> or maybe it's  --fixes lp:1111
[20:33] <Flimm> Thanks bueno, you're always here when I need help!
[23:46] <CaMason_> if I need to move my central branch to a different server, can I just copy/paste it?
[23:47] <bpierre> if it's a standalone branch, yes, it should work
[23:48] <CaMason_> time to try, then :)