[00:22] <Prodi> i've got a bzr+ssh server running in centralized environment, and i want it to run a command after anyone does a push to the server
[00:22] <Prodi> is there a hook i can use?
[00:23] <Prodi> post_push seems to say it only runs on the client side, but i'm looking for something on the server side
[09:14] <lifeless> thumper: so hows wikkid going ?
[09:14] <thumper> it's coming along
[09:14] <lifeless> cool
[09:14] <thumper> getting distracted by the terrible movie
[09:14] <lifeless> did you see my tweeted reply ?
[09:15] <lifeless> about twisted?
[09:16] <thumper> no
[09:16] <lifeless> ah
[09:16] <lifeless> so paste has no long poll supoprt
[09:16] <lifeless> I think twisted would be best to stay with
[09:17] <lifeless> use the twisted wsgi layer and use bits of paste in that
[09:17] <lifeless> but don't change the main server lop
[09:17] <thumper> I've not found any docs about twisted's wsgi layer
[09:17] <lifeless> xhttp://jcalderone.livejournal.com/51888.html
[09:18] <lifeless> http://jcalderone.livejournal.com/51888.html
[09:19] <lifeless> back in a bit
[11:50] <lornajane> I really can't figure out how to use bzr-svn, now wondering if in fact I'm expecting it to do something it doesn't actually do :)
[11:50] <lornajane> so I used bzr-svn to check out from subversion, branched that and worked on the branch
[11:51] <lornajane> when I came to commit back to the branch that was the subversion checkout, all my commits turned up in one individual merge commit
[11:52] <lornajane> I can sort of understand that, because that's how bzr works, but is there any way to commit multiple times to bzr and have them sent to svn individually?
[11:52] <james_w> hi lornajane
[11:52] <lornajane> (because at this rate I'm going to end up using git-svn and I'd really like to avoid that!!)
[11:52] <lornajane> hey james_w :)  Long time no see
[11:52] <james_w> indeed
[11:53] <james_w> so you branched and worked locally for a while?
[11:53] <lornajane> james_w: yes, I do this when I'm travelling and am offline
[11:53] <james_w> lornajane: how did you get those commits back to svn?
[11:54] <lornajane> james_w: pushed them to the branch that I originally made from svn
[11:54] <james_w> lornajane: odd, I would have expected that to do what you want
[11:54] <james_w> so I guess I'm not going to be much help for you :-)
[11:54] <lornajane> I committed several times before I pushed, and svn sees only a single merge commit in its log
[11:55] <lornajane> the whole point is that when I spend 2 days on the train, my team don't have to deal with a monster svn commit of 8 things lornajane did in the last 2 days
[11:56] <lornajane> now I'm giving a talk on source control at a big PHP conference and I'm quite determined to have as little git in it as possible, so I'm looking for information or pointers to places I should be looking for it
[11:56] <lornajane> the PHP community are way too excited by git
[11:58] <james_w> I know that there is a "dpush" command as well, but I thought it was for something else, not for solving this issue.
[11:59] <lornajane> well I played around a bit and it seems like bzr squashes commits by default, but retains some metadata about which changes went into them
[11:59] <lornajane> that's not part of the mainline history so it doesn't go across to svn, which does kind of make sense
[12:01] <lornajane> it just isn't what I wanted to do :)  So either I'm missing something, or I have unrealistic expectations of how this works, and either seems entirely plausible
[12:01] <james_w> right, if you do a "merge" at any point then you will get this behaviour for the revisions that you merged in
[12:02] <james_w> but if you just "push" then I didn't think that would happen
[12:02] <lornajane> ah, OK.  I'm playing some more now
[12:09] <lornajane> james_w: magic!!  That's absolutely what I was looking for :)
[12:10] <lornajane> I'll just play about with what happens when there are changes in svn while I'm developing etc but the simplest case was spot on - thanks so much!
[12:39] <jelmer> lornajane: if there are changes in svn, you can rebase (rather than merge) to keep your changes on the mainline
[12:39] <lornajane> jelmer: oh that's really helpful, I'm just trying to break things by making svn changes at the same time - because I know there probably will be when I do this in anger
[12:40] <lornajane> jelmer: so how do I do that? (feel free to just point me at the right place where I can RTFM) - and am I rebasing my checkout or my feature branch?
[12:52] <jelmer> lornajane: you would rebase your feature branch
[12:53] <jelmer> lornajane: and then push those rebased revisions into the checkout or directly to svn
[12:53] <lornajane> jelmer: this is making increasing amounts of sense :)
[12:53] <jelmer> lornajane: since rebase keeps the revisions on mainline all revisions will appear as individual commits in svn
[12:56] <goundy> hi
[12:56] <goundy> guys, there's still no way to make bazaar deleting a branch from a shared repository ?
[12:56] <goundy> rather than just deleting the branch folder
[12:57] <lornajane> jelmer: I get unknown command rebase ... am I out of date with something?
[13:00] <jelmer> lornajane: rebase is in a separate plugin, the bzr-rewrite plugin (originally named bzr-rebase)
[13:01] <lornajane> jelmer: ah, thanks
[13:11] <lornajane> jelmer: hey, that works beautifully.  Thanks so much for your assistance!
[13:11] <jelmer> lornajane: yw :-)
[13:12] <goundy> any idea where I can get a small private bzr branch for free guys ?c
[13:12] <goundy> I ain't got no commercial project yet, it's just a currently closed source one I'd like to host somewhere
[13:13] <goundy> launchpad asks for like 600$/year... a student like me can't pay that lol
[13:15] <jelmer> goundy: I'm not aware of anything; SourceForge perhaps?
[13:16] <goundy> jelmer, sourceforge doesn't have bazaar
[13:16] <goundy> only svn am I wrong ?
[13:16] <jelmer> goundy: it has bazaar (and git and mercurial) as well
[13:16] <goundy> ôO
[13:16] <goundy> gosh
[13:16] <goundy> I really didn't know about that
[13:16] <goundy> jelmer, am gonna check if they offer private hosting too. Thank you very much
[13:51] <goundy> jelmer, FYI, SF doesn't offer private hosting ;)
[15:25] <rlameiro> hello, is there some version control system only for my personal using?
[15:25] <rlameiro> without using a remote server?
[15:26] <rlameiro> or do i need to run a bz server on my desktop to use it?
[15:30] <lornajane> rlameiro: you can use bzr on your computer without needing a remote server
[15:32] <rlameiro> lornajane: thanks
[15:39] <rlameiro> lornajane: do i install only bzr? or do i need to install a bzr server?
[15:45] <lornajane> rlameiro: what platform do you use?
[15:45] <rlameiro> ubuntu
[15:45] <rlameiro> lornajane:
[15:46] <lornajane> rlameiro: I think you only need the bzr package
[15:47] <lornajane> rlameiro: I'm a bit of a newbie too though - but the user guide has helped me a lot!  Its here: http://doc.bazaar.canonical.com/latest/en/user-guide/index.html
[15:57] <jelmer> goundy: :-(
[15:57] <goundy> jelmer, that's really unfortunate.. I can find svn private & free stuff but nothing for bazaar ^^
[16:00] <jelmer> goundy: I'm not aware of anything else that might offer private hosting other than lp, perhaps ask on the bazaar list?
[16:01] <a212901390231901> just use any free webspace.
[16:01] <a212901390231901> don't need serverside bzr support.
[16:01] <goundy> jelmer, the bzr list is the only place I've not asked yet
[16:01] <goundy> a212901390231901, actually I'm aware I can use FTP mode
[16:02] <goundy> but i want to have a source browser too
[16:02] <goundy> and this is a problem
[16:04] <a212901390231901> 's not all that useful for private projects in my experience, the people who have access have local branches anyway
[16:04] <a212901390231901> and qbzr is better than loggerhead
[16:05] <goundy> a212901390231901, even if it's a private project I really need the browsing possiblity
[16:05] <goundy> qbzr ? am gonna check what it is
[16:06] <goundy> oh interesting :)
[16:06] <goundy> a212901390231901, have you ever used bazaar in FTP mode ?
[16:08] <a212901390231901> yeah. it won't fly for a kernel-sized project, but it's fine for anything more typical.
[16:10] <goundy> a212901390231901, I think am going to do this though
[16:10] <goundy> thanks :)
[17:46] <elmo> bah
[17:46] <elmo> I have a staging and a production branch, I'm trying to push to staging from production
[17:46] <elmo> but it's telling me production's diverged
[17:47] <elmo> nm
[20:26] <putrycy> hi! checkout otains snapshot (--lightweight) or complete branch. Is there a possiblity to get a 'havy' checkout but containng just few revisions back? Let's assume we have a long term project (for example OS;]) - we really don't need all revisions starting from the first.
[20:37] <putrycy> And second question: Is it possible to checkout/branch/whatever just a subdirectory instead of a hole branch?
[20:40] <awilkins> putrycy, http://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout
[20:41] <awilkins> putrycy, and   the --depth option on clone
[20:41] <putrycy> and another one question: Why do I have to be up to date with a branch to commit changes in local directory? Will it be fixed in a next bzr version?
[20:42] <putrycy> awilkins: thanks for replay
[20:42] <awilkins> putrycy, damn, wrong channel
[20:43] <awilkins> putrycy, Errrm, not sure bzr does sparse checkouts yet
[20:43] <putrycy> :)
[20:43] <putrycy> I'm starting to read... git? what's going on?:)
[20:43] <awilkins> putrycy, You don't have to be up to date to commit, unless it's a checkout
[20:44] <putrycy> awilkins: I'm talking about checkout...
[20:44] <awilkins> You can still commit locally, with an option
[20:44] <awilkins> But you then must be prepared to merge at some point
[20:44] <putrycy> OK
[20:44] <putrycy> the second manner - is it slow?
[20:45] <awilkins> putrycy, The same speed as a normal commit ; you're effectively deciding to make your local checkout a branch instead
[20:47] <putrycy> so, instead of checkout I could use branch that I merge every time I do some changes, right?
[20:48] <luke-jr> jelmer: so if I'm not allowed to simply ignore the bzr:revision-id:v3-list-*, what is the supported way to do this? :P
[20:50] <luke-jr> alternate idea: in rewriting the Svn repo, can I easily redo the bzr-to-svn for bzr-side revs?
[20:51] <luke-jr> I was thinking fast-export|fast-import, but bzr doesn't seem to support the latter sanely
[20:55] <jelmer> luke-jr: supported way to do what?
[20:56] <luke-jr> jelmer: ignoring the v3 branch layout screwup data while keeping the bzr rev info (committer, etc)
[20:59] <jelmer> luke-jr: hmm
[20:59] <jelmer> luke-jr: I would say this isn't really supported :-)
[20:59] <jelmer> luke-jr: fastexport/fastimport won't read the bzr-svn metadata
[21:00] <luke-jr> that was another approach I thought of
[21:00] <jelmer> luke-jr: I would recommend redoing the svn repo (svnadmin dump)
[21:00] <jelmer> luke-jr: and then generating new bzr-svn revprops (v4)
[21:00] <luke-jr> jelmer: redoing the svn repo how? :)
[21:00] <jelmer> luke-jr: svnadmin dumping it, editing the stream then reimporting
[21:00] <luke-jr> there was a number of months with overlapping svn/bzr commits
[21:00] <luke-jr> jelmer: how can I generate new svn revisions for the bzr commits?
[21:01] <putrycy>  It seems to be an answer to my question: As explained in later chapters, Bazaar also has support for lightweight checkouts of a branch, i.e. working trees with no local storage of history. Of course, disconnected usage is not available then but that’s a tradeoff you can decide to make if local disk space is really tight for you. Support for limited lookback into history - history horizons - is currently under development as well.
[21:01] <jelmer> luke-jr: you wouldn't generate new revisions, just modify the existing ones
[21:01] <putrycy> i.e. mainly the last sentence
[21:01] <luke-jr> jelmer: fabricate new v4 revprops from where?
[21:01] <jelmer> luke-jr: manually
[21:02] <luke-jr> in any case, it appears the script doing the bzr-to-svn imports was modifying stuff in the commit msg and such
[21:02] <luke-jr> is the v4 format documented?
[21:03] <luke-jr> my thought was to fudge a new svn repo with the svn-only history, then write a script to look at each subsequent revision; if svn-side, load the svndump; if bzr-side, rebase/fe-fi and push from present bzr-svn...
[21:04] <luke-jr> but fast-import seems to want to wipe all history and start over with the import
[21:06] <jelmer> luke-jr: the v4 format is documented in bzr-svn trunk
[21:07] <jelmer> luke-jr: yeah, that's true afaik (wrt fastimport)
[21:08] <luke-jr> jelmer: so there's no good way to move a bzr revision from one repo to another? :/
[21:08] <jelmer> luke-jr: you can push it, but that means the ancestry has to be in common as well obviously
[21:09] <luke-jr> yeah, which defeats the point
[21:09] <luke-jr> I just want to change the ancestor, nothing else at all
[21:09] <jelmer> luke-jr: if you're not pushing the ancestry then by definition it is not the same revision
[21:10] <luke-jr> semantics
[21:10] <awilkins> They are rather the core semantics of DVCS though
[21:11] <luke-jr> but they don't change what I want to do :)
[21:11] <luke-jr> if it's technically a new revision, fine, but I want it the same except ancestry :p
[21:15] <luke-jr> :/
[22:55] <putrycy> If I merge two branches then does current branch contain information about revision from merged branch? If no then is there a possiblity to merge a snapshot to branch?
[23:27] <luke-jr> jelmer: no way to put file-ids in revprops, is there? :\
[23:27] <luke-jr> putrycy: yes; see: bzr log -n0
[23:29] <thumper> beuno: ping