[01:09] <loswillios> hah!
[01:10]  * loswillios waits for james_w to appear
[01:40] <nir> What can cause this error on bzr merge ../other
[01:40] <nir> bzr: ERROR: [Errno 1] Operation not permitted
[01:41] <nir> both branches are local, both owned by me
[01:42] <nir> I merge changes in main in the other branch, but I can merge changes from other in main
[01:47] <nir> solved :-)
[01:48] <nir> One file was locked (mac os x feature) I don't have any idea why
[01:49] <nir> anyway, the error message is not helpful - it should show the path that failed
[01:51] <lifeless> nir: good point; its likely though that its an OSerror being raised rather than a bzr internal error that we can format and show useful data on
[01:51] <lifeless> we can certainly fix this particular case if you can provide the traceback and info for reproduction
=== Verterok is now known as Verterok_
[03:03] <minghua> Hi, I wonder if there is a way to combine multiple commits into a single one when doing "bzr rebase".
[03:04] <jelmer> minghua: not at the moment, no
[03:05] <minghua> jelmer: Thanks.
[03:05] <jelmer> minghua: Why would such a feature be useful?
[03:07] <minghua> jelmer: I am a translator.  I commit my work every day.  But it makes little sense to push or send patch of multiple changes when the translation is sent to upstream.
[03:08] <minghua> jelmer: If you read the bottom of http://wiki.debian.org/Teams/Dpkg/GitUsage you'll see the Debian dpkg upstream developers require translators to combine their changes before pushing.
[03:10] <jelmer> minghua: that's specific to git though
[03:10] <jelmer> when upstream merges your changes with bzr, there is only one additional revision on mainline
[03:10] <minghua> jelmer: Yes.  That's why I am asking if bzr has something similar...
[03:10] <jelmer> minghua: I don't see how it clutters mainlines revision history with zbr
[03:12] <minghua> jelmer: Oh, maybe that's the case.  I am a quite new bzr user.  But I just did a "bzr rebase", and I got an empty commit for "merge from upstream".
[03:13] <minghua> I did some translation changes in my branch, then I "bzr merge" with upstream, then I "bzr commit" as revision #n, finally I decided to do "bzr rebase".  And the revision #n is rebased as an empty commit.
[03:13] <jelmer> there shouldn't be a reason to do a rebase at all there
[03:14] <minghua> Hmm.  Maybe there isn't.  I should just run "bzr diff" across two branches.
[03:15] <jelmer> in general, if you do a merge of upstream+commit there's no need for a rebase and vice-versa
[03:16] <jelmer> minghua: If you don't use rebase at all, you won't clutter upstreams mainline
[03:16] <jelmer> and there will simply be one revision in mainline where your branch was merged
[03:16] <jelmer> no matter how many revisions it has
[03:17] <jelmer> "bzr log" will then show your revisions indented below that merge revision
[03:17] <jelmer> or not at all, depending on what you ask it to show
[03:17] <minghua> jelmer: I see.  Thanks for the explanation.
[03:26] <jelmer> minghua: what are you trying to do exactly? Are you submitting a patch to dpkg?
[03:32] <minghua> jelmer: No.  I was doing man-db's translation work, and upstream uses bzr.  I did some small incremental changes to the translation.
[03:32] <minghua> There were also upstream changes in between, and I merge and commit them once in a while.
[03:33] <minghua> Today I want to see how many changes I've made and what they are, so I did rebase, now all my local changes are on top.
[03:34] <minghua> I'll probably send a patch to upstream since I can push into the upstream repo, but that's not really relevant to the discussion.
[03:36] <minghua> jelmer: So in summary, what I was trying to do is to see my changes over the past months (which are acutally on a single file).  "bzr diff" across two branches should do that.  It would be nicer to see them individually, though, and I don't know how to do that yet.
[03:38] <jelmer> bzr diff -c <revno> should show you the changes in an individual commit
[03:43] <minghua> jelmer: But that requires me to go through "bzr log" to get the revno of my commits, doesn't it?
[03:51] <jelmer> yep - you're looking for something that will present a concatenation of all those patches?
[03:51] <jelmer> I guess something like "for I in `seq FROM-REVNO..TO-REVNO`; do bzr diff -c $I; done" can do that, but I'm not aware of any command in bzr that can
[03:52] <minghua> Wouldn't that include changes I merged from upstream as well?
[03:52] <minghua> I am looking for a way to see individual patches of my commits, and my commits only.
[03:53] <jelmer> ahh, ok
[03:53] <minghua> Then say if I'm doing both translation work and code changes, I may want to put all my translation changes in one commit to upstream, but separate the translation and the code.
[03:54] <minghua> I admit that's quite a corner case, of course.  And I probably should use two different branches for that.
[03:54] <radix> are you trying to maintain a branch long-term?
[03:54] <radix> because indeed, you're probably much better off using specific, task-oriented branches.
[03:55] <minghua> It will be long-term if I don't have much time to work on it...
[04:39] <lifeless> minghua: rebase destroys history and collaboration; if you don't plan to collaborate on the translations, you can rebase safely. But if you plan to collaborate, rebasing is a significant negative.
[04:41] <minghua> lifeless: No, no collaboration so far.  Thanks for the warning, though. :-)
[04:41] <lifeless> np
[04:41] <lifeless> its a significant part of why rebase isn't a common workflow in bzr land; and one of the things I find most weird about the git culture
[04:42] <minghua> I am from SVN land.  Both cultures are new to me, I am just trying to figure out what is the best way to construct my workflow.
[04:43] <lifeless> ok
=== cprov-lunch is now known as cprov
=== kiko-afk is now known as kiko
=== cprov is now known as cprov-away
[13:18] <dato> if I `bzr pulled`, and then I decide eg. I pulled something I didn't want in my branch yet, is there a way to go back that isn't `bzr uncommit; bzr uncommit; bzr uncommit` ?
[13:22] <fullermd> pull from yourself at the chosen rev?
[13:23] <dato> `b pull -r 1284 --overwrite . ` did the trick, thanks fullermd
[13:41] <loswillios> james_w: hej
[13:41] <loswillios> james_w: I fixed it
[13:42] <loswillios> turns out, /usr/lib/python2.4/site-packages/bzrlib was missing __init__.py and such stuff
[13:46] <james_w> loswillios: wow. good catch.
[13:56] <loswillios> the debian package is missing some symlinks here. manually symlinking the stuff works now
[13:58] <james_w> loswillios: you're running a backported version?
[13:59] <loswillios> yep
[14:00] <loswillios> but the package in etch was missing the symlinks also (bzr-0.11, lol)
[14:00] <loswillios> I begin to think, that something with this debian installation is wrong
[14:00] <james_w> it sounds like something funky might be going on with python-central
[14:01] <dato> loswillios: how are you installing the .deb?
[14:01] <dato> loswillios: the .deb itself won't have the symlinks, they are created at instalation time
[14:01] <loswillios> yes.. they symlinked each file seperatly. symlinking the whole /usr/share/pycentral/bzr/site-packages/ to site-packages did the trick
[14:02] <james_w> dato: I believe he said aptitude yesterday.
[14:02] <loswillios> dato: yeah, I thought so. with aptitude / apt-get
[14:02] <dato> ok
[16:10] <ubotu> New bug: #165014 in bzr "IPv6 support" [Undecided,New] https://launchpad.net/bugs/165014
[17:21] <jelmer> lifeless: ping
=== YGingras__ is now known as YGingras
=== abadger_afk is now known as abadger
=== abadger is now known as abadger1999
[17:50] <james_w> jelmer: congratulations on your DM advocation.
[17:55] <jelmer> james_w: thanks!
=== weigon_ is now known as weigon
=== kiko is now known as kiko-afk
[18:25] <mwhudson> bzr: ERROR: Installed bzr version 0.93.0.dev.0 is too old to be used with bzr-svn, at least 1.0 required
=== Verterok_ is now known as Verterok
[18:26] <mwhudson> jelmer: where do i get bzr 1.0 ? :)
[18:38] <fullermd> We're keeping it in svn.  Just use bzr-svn to check it out...
[18:38] <Odd_Bloke> ^_^
[18:39] <mwhudson> heh
[18:45] <jelmer> mwhudson: whoops :-) Fixed now, thanks.
[18:46] <jelmer> mwhudson: btw, that bug you hit pushing pydoctor should be fixed now
[18:46] <jelmer> mwhudson: although pushing should still be somewhat slow
[18:47]  * mwhudson tries
[18:53] <mwhudson> "finding branches" is still pretty slow
[18:53] <jelmer> mwhudson: yeah, I hope to fix that for 0.4.5
[18:53] <jelmer> its result can be completely cached, with a little bit of work
[18:53] <mwhudson> jelmer: will it get cached once it's completed?
[18:54] <jelmer> mwhudson: bits of it, but not completely
[18:54] <mwhudson> i see
[18:55] <jelmer> it uses svn metadata to find those branches and that metadata already gets cached
[19:15] <mwhudson> puh, conflicts
[19:15] <jelmer> mwhudson: during svn push?
[19:16] <mwhudson> yeah, but legitimate ones
[19:22] <mwhudson> how i wish svn had uncommit
[19:22] <mwhudson> pushing again, let's see how that goes
[19:34] <mwhudson> !paste
[19:34] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[19:35] <mwhudson> jelmer: hee! http://paste.ubuntu-nl.org/45816/
[19:35] <mwhudson> radix: you are being mailbombed, sorry about that
[19:36] <jelmer> :-(
[19:36] <jelmer> mwhudson: this is with subversion 1.4?
[19:37] <mwhudson> jelmer: it's whatever's in gutsy
[19:38] <mwhudson> jelmer: it looks like 11 commits actually ended up in svn though
[19:39] <mwhudson> jelmer: i'm trying again after 'ulimit -c unlimited'
[19:40] <lifeless> jelmer: pong
[19:41] <mwhudson> wth
[19:41] <mwhudson> i accidentally ^Ced it
[19:42] <mwhudson> and this: http://paste.ubuntu-nl.org/45819/ happened
[19:42] <jelmer> lifeless: 'morning
[19:42] <jelmer> lifeless: I was wondering if you could advocate my application to become a Debian Maintainer?
[19:42] <lifeless> sure
[19:44] <jelmer> It should be a matter of replying to the thread in debian-newmaint
[19:44] <jelmer> http://lists.debian.org/debian-newmaint/2007/11/msg00157.html
[19:44] <mwhudson> hi lifeless
[19:45] <mwhudson> there was something i wanted to ask you, but i can't remember what it was
[19:45] <dato> jelmer: if you'd bounce him the mail, replying would keep the threading
[19:46] <jelmer> dato: good point - just did so
[19:52] <lifeless> mwhudson: :)
[19:57] <samiam> morning all
[19:58] <samiam> I have a really quick and possibly stupid question
[19:58] <samiam> is it possible to change a log entry for a commit, post-commit?
[19:58] <samiam> I just realized I had made an error and would like to correct it
[19:58] <dato> nope.
[19:58] <dato> but if it's the last commit
[19:58] <dato> you can `bzr uncommit` it
[19:58] <dato> and commit again, with a fixed message
[19:58] <samiam> good point
[19:59] <samiam> it isn't the last
[19:59] <samiam> its no big deal, I just thought that this might come up from time to time and felt I should investigate now
[19:59] <samiam> its a single-user repo anyway
[19:59] <samiam> thanks dato
[19:59] <mwhudson> at least in conception, bazaar revisions are totally immutable
[20:00] <samiam> mwhudson: I had never really seen this capability in other vcs' so I thought I would ask just in case
[20:01] <samiam> truthfully, that would be a really bad thing to have in a vcs, because you'd lose the integrity or value of the commit logs
[20:01] <mwhudson> samiam: right :)
[20:01] <mwhudson> samiam: you can use rebase in situations like this, if it's really important
[20:01] <mwhudson> (probably not for a commit message, tbh)
[20:01] <samiam> it isn't important at all
[20:02] <samiam> just exploring bzr right now and using it for personal work
[20:02] <mwhudson> cool
[20:02] <samiam> thanks for the feedback mwhudson
[20:03] <mwhudson> np
[20:07]  * mwhudson stares at merge.py
[20:08] <radix> mwhudson: heh
[20:08] <radix> mwhudson: when are you going to start using bzr? :)
[20:28] <mwhudson_> jelmer: so that run got nixed by my machine crashing :)
=== mwhudson_ is now known as mwhudson
[20:30] <jelmer> not due to bzr-svn, I hope ? :-)
[20:30] <mwhudson> jelmer: don't think so :)
[20:41] <abentley> hey mwhudson, how goes?
[20:49] <radix> _there's_ the spam :)
[20:50] <radix> mwhudson: use Launchpad!
[20:54] <fullermd> Hm.  I think progress bars on check are a little squirrely.
[20:54] <lifeless> radix: mwhudson is using bzr. merge.py is in the guts
[20:55] <fullermd> Unless checking versionedfile 0 really does take about 10 times as long as the other 200-some, I suspect it's doing something other than it claims at that time.
[20:55] <lifeless> fullermd: enumerating the versionedfiles requires a table scan in packs
[20:56] <fullermd> I'm using good old-fashioned knits.
[20:56] <lifeless> ah, then its disk IO
[20:56] <fullermd> All in cache.
[20:56] <lifeless> bleh
[20:56] <lifeless> hit ctrl-\ and type bt CR
[20:56] <fullermd> python's getting 100% CPU while it's doing whatever it's doing there...
[20:57] <fullermd> Inner frame at the bottom?
[20:57] <lifeless> yes
[20:57] <lifeless> but look up the stack for the relevant function names
[20:59] <fullermd> Seems to be spending a lot of time in xml_serializer stuff.
[20:59] <lifeless> so look up
[20:59] <lifeless> some function will probably have iter or some hint in the name
[21:00] <fullermd> Seems to be mostly in repository._generate_text_key_index()
[21:00] <fullermd> It probably spends about 20 seconds in that versioned file 0/xxx on a branch where check runs in under a minute.
[21:01] <lifeless> ok
[21:01] <fullermd> Lemme halt it a couple times for a sampling...
[21:01] <lifeless> so that is scanning all the inventories
[21:01] <lifeless> it's meant to do a progress bar for that
[21:01] <lifeless> but it's reasonable for it to be expensive, its the dominating data structure of bzr
[21:03] <fullermd> It seems new, though.  Nowhere near that much time elapsed between the revision checking and versionedfile checking last week or so.
[21:03] <fullermd> It used to just start counting as soon as it was in versionedfile.
[21:07] <fullermd> A few samplings within the process: http://paste.ubuntu-nl.org/45844/
[21:07] <mwhudson> radix: >:)
[21:08] <mwhudson> abentley: good thanks, about to have dinner
[21:11] <fullermd> Wait, "unreferenced text versions" can't possible be right.  It's within 1% of total revisions * file-ids; that's more texts than should exist period.
[21:15] <abentley> lifeless: The thing about KindChange is that it must appear in the list at the end, and diff_text must be second.
[21:15] <luislavena> hello guys.
[21:15] <lifeless> abentley: KindChange I can understand; why Text ?
[21:15] <lifeless> hi luislavena
[21:15] <luislavena> quick question: anyone using bzr-gtk on windows?
[21:15] <luislavena> hi lifeless
[21:15] <lifeless> fullermd: have you reconciled this repository with 0.92 or bzr.dev ?
[21:16] <lifeless> luislavena: I know people have managed to get it to work, and bzr-tortoise incorporates parts of it
[21:16] <abentley> Difftext must be second-last, because it's a catch-all.  If it's early, more specialized diffs will never be used.
[21:16] <luislavena> lifeless: I'm using Olive without problems, but the diff it generates aren't colorified :P
[21:17] <lifeless> abentley: I don't think it has to be second-last. I think it has to be after anything else that would diff the same files
[21:17] <lifeless> abentley: same with DiffSymlink
[21:17] <lifeless> abentley: if I had a variation on that, I have to put it before DiffSymlink
[21:18] <lifeless> abentley: in fact, *all* of these have an ordering. I don't think there is a problem in allowing a certain amount of rope though :)
[21:18] <abentley> Yes, but diff_text is an instance and can't appear in the factory list at all.
[21:19] <abentley> So it must either appear before all registered factories (disaster) or after (safe).
[21:19] <abentley> And KindChange must appear after diff_text.
[21:19] <fullermd> lifeless: Yep.  http://paste.ubuntu-nl.org/45846/
[21:20] <lifeless> abentley: oh; I must have glitched on this. I thought it would still be a factory
[21:20] <lifeless> abentley: let me check the patch again
[21:20] <abentley> No, its construction depends on what parameters are passed to show_diff_trees.
[21:20] <ubotu> New bug: #165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Triaged] https://launchpad.net/bugs/165061
=== kiko-afk is now known as kiko
[21:22] <lifeless> abentley: so the old and new label parameters seem applicable to all Diff classes
[21:22] <abentley> I don't think they are.
[21:22] <lifeless> abentley: and the internal_diff parameter is indeed a touch tricky
[21:23] <abentley> It's purely a unified diff formatting quirk.
[21:23] <abentley> It's so that patch -p1 works.
[21:23] <lifeless> abentley: they change the path prefix don't they ? we should be showing that on e.g. symlink changes too
[21:23] <abentley> patch can't understand symlink changes.
[21:23] <lifeless> thats true
[21:24] <lifeless> but humans will be weirded out by something like:
[21:24] <abentley> We've never used them for anything except unified diff formatting.
[21:24] <lifeless> old/text   new/text
[21:24] <lifeless> ...
[21:24] <abentley> We don't use them in the === modified message.
[21:24] <lifeless> base/link  changed/link
[21:24] <lifeless> oh hmm
[21:24] <lifeless> well.
[21:25] <lifeless> Like I said, if you don't agree - and it seems like there is good reason that its not trivial to do the entire thing I suggested, its fine as is
[21:25] <lifeless> I still think having Diff.__init__(self, a_diff_tree): would be good
[21:25] <abentley> Okay.  So now we let poolie decide whether it's 1.0-worthy.
[21:25] <lifeless> because it opens the door to doing the rest later with less of an API change
[21:26] <abentley> I've done that change.
[21:26] <lifeless> sweet
[21:26] <abentley> Or rather, I created a real factory.
[21:26] <lifeless> I'm confused. Do you have a further tweak beyond your latest mail?
[21:26] <abentley> So that we can still construct the Diff classes in a straightforwardway.
[21:27] <abentley> I have a further tweak, if we want it.
[21:28] <abentley> But it doesn't allow us to put DiffKindChange in the factory list, which was the reason for your suggestion.
[21:28] <lifeless> right
[21:28] <lifeless> Do you think it looks nice other than that? If so, lets do it.
[21:28] <abentley> Sure.
[21:29] <lifeless> I'll be on the phone with poolie in 1.5 hours
[21:29] <lifeless> I'll raise this patch to his attention if it's not already there.
[21:29] <lifeless> brb
=== me_too is now known as too_short
=== too_short is now known as me_too
[21:31] <lifeless> luislavena: I would suggest filing a bug on bzr-gtk
[21:32] <luislavena> lifeless: I'm googling for something like this before, maybe I missed something, but guess not.
[21:34] <cbx33> hey all
[21:35] <lifeless> hi
[21:35] <luislavena> cbx33: hi
[21:35] <cbx33> hi luislavena
[21:44] <luislavena> lifeless: done, there is no info about this on the web, so submited a new bug report to bzr-gtk team. thank you.
[21:49] <abentley> fullermd: versionedfile data and the inventory data are stored along different axes.  So doing the first versionedfile requires reading most inventory revisions.  That data's then cached.
[21:50] <lifeless> abentley: my lower memory reconcile changed check too
[21:50] <fullermd> Well, but it seems new, though.  It used to just count up through the revisions, then count up through the vf's, without the big pause there.
[21:50] <lifeless> abentley: so it no longer incrementally generates a inventory->text cache at all.
[21:50] <lifeless> fullermd: it should be faster overall
[21:50] <fullermd> That might do it.  When the vf numbers do start counting, they seem to go a lot faster than they used to.
[21:51] <lifeless> fullermd: if you run check with -v you should get a list of the text versions that are not referenced
[21:51] <lifeless> fullermd: and we can dig into why they are not being cleaned up
[21:53] <fullermd> It's not the existence; it's the wildly extreme number.  I don't recall doing anything special in the history of these branches; there shouldn't be that many texts ever existing, much less unreferenced.
[21:55] <fullermd> There were some uncommits or discarded branch revs, but those would still be ref'd, AIUI.  And this is a fresh branch, so it wouldn't bring those along.
[21:55] <fullermd> -v doesn't output anything different.
[21:55] <dato> jelmer: that was fast, eh? (re joeyh's mail)
[21:56] <lifeless> fullermd: ok thats weird. Is this a repo I can get access to ?
[21:58] <fullermd> Probably not...   I can make a nothing-branch that starts showing up unref'd text versions, though...
[22:00] <lifeless> fullermd: if its in the same repo thats why
[22:01] <fullermd> No, in a fresh standalone.
[22:01] <jelmer> dato: wow, that /is/ fast
[22:02] <dato> :)
[22:02] <fullermd> lifeless: http://paste.ubuntu-nl.org/45848/
[22:04] <fullermd> lifeless: It seems to need the second file; just stuffing text in foo and committing more revs doesn't make it show up.
[22:04] <lifeless> dato: what happened ?
[22:06] <lifeless> fullermd: blarh. please file a bug
[22:12] <lifeless> fullermd: (I reproduced it, just need a note to track it)
[22:12]  * fullermd nods.
[22:12] <fullermd> Probably a check bug, and not that we're actually making extra texts?
[22:14] <dato> lifeless: he was already added to the debian-maintainers keyring
[22:14] <fullermd> Filed.
[22:19] <lifeless> dato: rofl
[22:21] <ubotu> New bug: #165071 in bzr "check reports spurious unreferenced texts" [Undecided,New] https://launchpad.net/bugs/165071
[22:31] <jelmer> hmm, the quick reference doesn't contain any info about "
[22:31] <jelmer> bzr send"
[22:31] <jelmer> I wonder whether that should be considered a bug?
[23:05] <lifeless> jelmer: yes
[23:09] <sdh> can anybody tell me a good resource to learn how to use bzr in a mixed-type environment
[23:09] <sdh> so i have a central repos, and can branch onto my laptop, say, commit there, then commit all back later?
[23:09] <sdh> e.g. when on plane
[23:10] <sdh> probably not explaining well :)
[23:10] <lifeless> sdh: the tutorial probably is enough
[23:11] <sdh> lifeless: just realiesd that wasn't one of the docs i read, heh. thanks. :>
[23:12] <lifeless> :)
[23:12] <lifeless> please do ask for more details and hints once you've given it a shot
[23:12] <sdh> thanks... i did read lots... of blog posts ;)
[23:13] <sdh> so far today i've tried git, hg and now bzr... bzr "feels" good so far :)
[23:13] <lifeless> excellent
[23:14] <sdh> i watched a video of linus talking about git at google and learnt two things
[23:14] <sdh> 1) git is supposedly fast
[23:14] <sdh> 2) linus is even more arrogant than i thought
[23:14] <sdh> :)
[23:15] <fullermd> Pfft.  Obviously, you are Ugly And Stupid   :p
[23:15] <sdh> haha, that's the one ;)
[23:21] <ubotu> New bug: #165080 in bzr "Quick Start Guide doesn't document "bzr send"" [Undecided,New] https://launchpad.net/bugs/165080
[23:44] <sdh> is there a way to push to the parent branch without specifying it explicityly?
[23:44] <sdh> explicitly, even
[23:50] <abentley> sdh: just "bzr push".
[23:50] <abentley> That will push to the remembered branch.
[23:50] <mathrick> hiya
[23:50] <abentley> Which is actually a different location.
[23:51] <abentley> But you don't have to specify it explicitly each time.
[23:51] <mathrick> what is the right foo to get a working tree in a treeless branch?
[23:51] <sdh> it didn't work for me, i got:
[23:51] <abentley> mathrick: bzr checkout .
[23:51] <sdh> oh it works after the first push :)
[23:51] <abentley> sdh: right.
[23:51] <sdh> thanks
[23:52] <abentley> sdh: np
[23:52] <abentley> mathrick: or on recent Bazaars, "bzr reconfigure --tree".
[23:52] <mathrick> oh, already checkouted :)
[23:52] <mathrick> and yes, it's 0.93, so recent
[23:54] <fullermd> Mmp.  We probably need a good section in the docs on reconfig (and that alias).  I like to think I have a reasonable knowledge of bzr, but I couldn't guess what "Reconfigure to a tree" means.
[23:57] <mathrick> small inconsistency: bzr status takes -V, but bzr ls doesn't
[23:57] <mathrick> you have to use --versioned
[23:59] <lifeless> mathrick: yah, IIRC we put -V in for ui friendliness with svn
[23:59] <mathrick> it's a good alias
[23:59] <lifeless> please file a bug about -V for ls