[00:14] <Kilroo> I really need to try to map out how I think we ought to use bzr where I work
[00:14] <Kilroo> because otherwise I think we'll probably continue with our rather slow and problematic adoption of svn.
[01:02] <amanica> what other tecnologies are you using?
[03:54] <KhaZ> Hello!  Perhaps a silly question, but I'm used to Perforce, and not sure the equivalent in bzr.  Say I have a file and I want to make a 'copy' of it in bzr while retaining it's history.  This is typically called an 'integrate' for Perforce - is there something similar in bzr?
[04:02] <Basic> Just 1 file?
[04:04] <KhaZ> Yeah
[04:04] <KhaZ> Basically I just want to 'copy' the file.
[04:05] <KhaZ> There's a bzr mv, but not a cp, or at least nothing I can see that's equiv.
[04:07] <Basic> like this?http://bazaar-vcs.org/BzrFileCopies
[04:08] <Basic> looks like open issue, confirm issue, but unresolved
[04:08] <Basic> https://bugs.launchpad.net/bzr/+bug/269095
[04:08] <KhaZ> Ah.
[04:08] <Basic> Perforce is specifically mentioned in the bug report
[04:08] <KhaZ> That's too bad.
[04:09] <KhaZ> I'll go read, but do you know if there's a bzr analogue?
[04:09] <Basic> no, the bug report, is really a feature request
[04:09] <Basic> functionally is "confirmed" missing, there was a blueprint created to address the missing functionality, but no one has picked it up to write the code
[04:10] <KhaZ> Right.
[04:10] <KhaZ> OK, well thanks for sending me the link.
[04:12] <Basic> I'm just community memory, maybe one of the core dev will answer/followup with more details
[04:17] <KhaZ> Heh; well either way it sounds like I can't accomplishw hat I need to do.  I guess revision history isn't super essential for this stuff yet.
[04:18] <Basic> per repo it is
[05:01] <BasicTheProgram> Is there a way to cancel a PQM submit?
[06:05] <BasicOSX> Anyone have privs to uncommit releases branches?
[06:05] <BasicOSX> details on ML about my mistake :-(
[10:12] <Peng_> Hey, there are tags in bzr.dev now? Cool!
[11:19] <Peng_> Whoever said that bzr is pulling too much data is right. The main .pack for bzr.dev is ~125 MB, but my repo is ~185.
[11:19] <Peng_> I do have some extra revisions in my repo, but not 60 MB of them!
[12:03] <verterok> LarstiQ: apologize the delay, yes I saw the "unofficial" release
[12:03] <verterok> LarstiQ: thanks for pointing it out
[12:41] <lifeless> Peng_: well, clearly you do
[12:41] <lifeless> Peng_: perhaps you have stale packs?
[12:44] <Peng_> lifeless: Hmm, that's possible.
[12:45] <Peng_> lifeless: None.
[12:47] <Peng_> Hmm, I only have 167 MB of packs. Why did I think it was 185?
[13:09] <LarstiQ> verterok: no problem
[13:40] <zand3r> Does anyone know if the new storage format for bzr 2 will support a "bzr cp" command per bug #269095 - I'm deciding which vcs to opt for an whilst I don't see lack of a cp command as a show stopper I can see it being useful in the future.
[14:11] <zand3r> How long after an official release does the Windows installer generally appear? The current download for Windows is 1.14.1
[14:13] <Peng_> Ehh, it's supposed to be a few days, but I dunno what it usually is.
[14:15] <zand3r> Thanks - I'll look out for it
[18:12] <lifeless> zand3r: it won't; that may be a 3.0 goal.
[18:20] <lifeless> á
[18:56] <zand3r> lifeless: Thanks... I'm surprised that the cp command doesn't carry more weight but at the same time I can't immediately see why I'd need one so understand why it may not be a priority.
[19:00] <zand3r> Actually mercurial's description of their copy command does show a good use case - its different to what bzr bug #269095 describes.
[19:05] <Peng_> zand3r: It isn't necessarily just about weight; there would have to be design changes for copies to be possible, and it's not that high of a priority.
[19:06] <zand3r> Peng_:  Sorry for my waffling... I'm currently deciding which vcs we should standardise on and for some reason felt the need to spew odd thoughts into the irc channel
[19:10] <Peng_> Asking a few questions is nothin' to be sorry about.
[19:28] <pygi> hi
[19:31] <Peng_> Hello.
[19:49] <lifeless> zand3r: we have some designs in mind, its a matter of making them good, not just takckin it on :)
[20:21] <spirov92> I
[20:21] <spirov92> I
[20:21] <spirov92> I'm new to bzr. is it good for working in teams?
[20:21] <spirov92> btw sorry, the quote key is close to return
[20:23] <spirov92> btw, anyone here?
[20:24] <nadavoid> He
[20:24] <nadavoid> Hi
[20:24] <nadavoid> I'm pretty new to bzr too.
[20:24] <nadavoid> I've used it on a couple of projects, just solo though.
[20:25] <spirov92> but I'll be working with other people
[20:25] <nadavoid> I think it is supposed to be very good for teams.  One reason is that you can start off solo, then merge your changes with others if you want.
[20:26] <spirov92> but is it easy to synchronize your work, checkout, etc?
[20:26] <nadavoid> I believe so. As I understand it, that's the main point of using bzr.
[20:27] <nadavoid> I'll pass you some links I've found that should address working with teams.
[20:28] <spirov92> nadavoid: I'm listening
[20:29] <nadavoid> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
[20:29] <nadavoid> There's a section on "Sharing with peers" and one on "Team collaboration, central style"
[20:29] <nadavoid> and on on "Team collaboration, distributed style"
[20:30] <nadavoid> https://launchpad.net/ is an option for centrally hosting a bzr project
[20:31] <nadavoid> http://bazaar-vcs.org/BazaarForWebDevs - more about just publishing to a server
[20:31] <spirov92> for web devs? just what I need
[20:32] <nadavoid> what sort of web dev are you doing? (I'm a drupal dev)
[20:32] <spirov92> php, using the Kohana framework
[20:33] <spirov92> the guys on #kohana told me about bzr in the first place
[20:33] <nadavoid> cool
[20:33] <nadavoid> I don't think I've heard of kohana before.
[20:33] <nadavoid> it looks like the main commands you'd need to use are "bzr pull" or "bzr merge"
[20:33] <nadavoid> ... for staying synced.
[20:34] <nadavoid> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style <-- looks like a good chapter
[20:35] <nadavoid> This is the only other site I have bookmarked: http://ubuntuswitch.wordpress.com/2009/03/26/version-control-bazaar-for-web-developers/
[20:35] <nadavoid> oh, and this one too... http://925html.com/techniques/using-bazaar-on-a-mac/
[20:35] <spirov92> mac is too expensive, I use Linux
[20:36] <nadavoid> there still might possibly be some info you can use in that article.
[20:37] <nadavoid> This would definitely be my starting point - http://bazaar-vcs.org/Documentation
[20:40] <nadavoid> Hope that's all helpful to you. I've been really enjoying using bzr, and I hope to have an opportunity to try the merging/collaboration features soon.  But now, I must go outdoors and clean up the yard some.  See ya!
[20:41] <spirov92> nadavoid: thanks a lot, I'll check these out
[22:01] <Kissaki> how do I change bzrs timezone? It does commit with UTC+2 instead of +1
[22:03] <Peng_> Kissaki: It uses the system timezone.
[22:05] <Kissaki> mh, but it does not...
[22:06] <Kissaki> it does say 23:00 +0200
[22:06] <Kissaki> and on my pc it's 23:00 +1
[22:07] <Peng_> Are you sure? Do other shell applications agree? Other Python applications?
[22:08] <LarstiQ> date vs date -u
[22:08] <LarstiQ> Kissaki: ^^
[22:08] <Kissaki> I'm on xp
[22:09] <LarstiQ> d'oh!
[22:09] <Kissaki> I'm using bzr on a svn server
[22:09] <Kissaki> (even worse)
[22:09] <Kissaki> :P
[22:09] <Kissaki> and on trac, it says +0200
[22:09] <LarstiQ> note that trac may do some timezone manipulation too
[22:10] <Kissaki> yeah
[22:10] <LarstiQ> Kissaki: is there no `date` utility for windows?
[22:10] <Kissaki> well, trac does list bazaars attributes on the commit log page
[22:10] <LarstiQ> Kissaki: it is of course always possible that something might be wrong, but so far all the reported cases have been thinking their timezone was not what it was
[22:10] <Kissaki> which is not there on svn
[22:11] <Kissaki> and that one does have +0200
[22:11] <LarstiQ> Kissaki: ok
[22:11] <LarstiQ> Kissaki: I'm not sure which timestamp gets used with svn, the server or the local one.
[22:11] <LarstiQ> Kissaki: could you check the time on the svn server?
[22:12] <Kissaki> sure, that would be the linux server then?
[22:13] <Kissaki> that has +1, my local time
[22:13] <LarstiQ> hmm
[22:13] <LarstiQ> Kissaki: which timezone are you in?
[22:13] <LarstiQ> Kissaki: it's 23:13 here, and I'm in +2
[22:13] <Kissaki> Germany, UTC+1
[22:13] <LarstiQ> Kissaki: CEST to be specific.
[22:14] <LarstiQ> Kissaki: no, you're in UTC+2 then :)
[22:14] <LarstiQ> Kissaki: daylight saving time
[22:14] <Kissaki> haha, well
[22:14] <Kissaki> then I'm in +2, the server is on +2
[22:14] <LarstiQ> which is why I always recommend comparing `date` and `date -u` output
[22:14] <spirov92> yeah, dst is crazy
[22:15] <LarstiQ> spirov92: it's fun!
[22:15] <Kissaki> hmm
[22:15] <LarstiQ> spirov92: but not as fun as leap seconds
[22:15] <Kissaki> maybe one of those other svn users is wrong then?...
[22:15] <LarstiQ> Kissaki: so, bzr shows +2, and you are in +2. Is there something else out of sync?
[22:16] <Kissaki> well, I wondered when I did commit, and 35 mins later someone else did commit. In the end it was 25 mins earlier (and still is) in my bzr log
[22:17] <Kissaki> when I saw the bzr attribute in the commit on trac, I thought that was the problem. But it seems I did mix that up
[22:17] <LarstiQ> Kissaki: even when you account for different timezones?
[22:18] <Kissaki> hm?
[22:18] <LarstiQ> Kissaki: ie, looking at bzr.dev timestamps, you see  Sat 2009-05-23 07:40:24 +0100 and Fri 2009-05-22 23:55:52 -0500
[22:19] <Kissaki> don't get what you mean or what you're trying to tell me
[22:19] <LarstiQ> Kissaki: so, when you commit, it records the time that the local computer tells it to
[22:20] <LarstiQ> Kissaki: if all the computers are configured, someone in Australia can commit, and then 5 minutes later someone in the US could commit
[22:20] <LarstiQ> Kissaki: if you look at just the hours, it would seem like time was reversed
[22:20] <LarstiQ> Kissaki: but if you normalize to UTC, you would see that in actual fact time is still going forward
[22:21] <LarstiQ> Kissaki: of course, this is assuming that the computers are telling the correct time
[22:21] <Kissaki> on trac it's all correct
[22:21] <LarstiQ> Kissaki: you could set your clock to 1900 and do a commit, then that would show as a timestamp
[22:21] <LarstiQ> (assuming the datetime structure handles that)
[22:21] <Kissaki> well, it's just a problem with qlog it seems
[22:21] <Kissaki> as trac on the svn server does display everything correctly
[22:22] <LarstiQ> Kissaki: do you have a screenshot?
[22:22] <LarstiQ> or two, to compare trac and qlog
[22:22] <Kissaki> sure, one mom
[22:24] <Kissaki> LarstiQ: http://www.abload.de/img/tmpoesu.png
[22:24] <Kissaki> as you can see, bzr also does have different rev numbers from the svn server
[22:27] <LarstiQ> Kissaki: svn revs not matching bzr revs will almost always be the case
[22:27] <Kissaki> k
[22:27] <LarstiQ> Kissaki: if you look at `bzr log` (with bzr-svn enabled) you'll see it reports the original svn rev
[22:29] <LarstiQ> Kissaki: I'm a bit annoyed that both trac and qlog are not showing the utc offset.
[22:29] <LarstiQ> Kissaki: could you check your trac preferences for the timezone setting?
[22:30] <LarstiQ> Kissaki: if trac and qlog think they are working with the same offset, there is indeed a bug somewhere
[22:31] <LarstiQ> Kissaki: if trac's offset is 1 higher than qlog's, there might still be a bug in that one of the two (probably qlog) is displaying time with the wrong timezone
[22:32] <LarstiQ> but if they are genuinely showing time in different timezones, they are doing the correct thing
[22:32] <Kissaki> hm, can't find a timezone setting in trac.ini
[22:32] <LarstiQ> even if I dislike not having the timezone information provided
[22:33] <Kissaki> on trac, on a changeset it does provide the commit time, as well as the bzr attribute: bzr:timestamp: 2009-05-23 00:27:59.858999968 +0200
[22:33] <LarstiQ> hmm, there doesn't seem to be a timezone setting in 0.10
[22:33] <Kissaki> while they're the same apart from the "+0200"
[22:34] <Kissaki> if it would help, I could give you the rep url
[22:34] <Kissaki> and/or trac
[22:34] <LarstiQ> hmm, but it isn't 00:27 yet in 2009-05-23 +020
[22:34] <Kissaki> that was yesterday
[22:34] <Kissaki> or not
[22:34] <Kissaki> today 00:27
[22:35] <Kissaki> so 23 hours before now
[22:35] <LarstiQ> oh, *slap*
[22:35] <Kissaki> *= ago
[22:35] <LarstiQ> yes, you're right
[22:35] <Kissaki> :)
[22:35] <LarstiQ> it is my bedtime, you see ;)
[22:35] <LarstiQ> Kissaki: trac 0.11 (at my work at least), has a trac.cgi/preferences
[22:36] <LarstiQ> wich has a 'Date & Time' tab
[22:36] <LarstiQ> the only thing you can change is the timezone
[22:36] <Kissaki> using it with wsgi on apache
[22:36] <LarstiQ> Kissaki: point is, /preferences as a sibling of /wiki
[22:36] <Kissaki> can't find a preferences, just conf/trac.ini
[22:37] <LarstiQ> Kissaki: in the web view that is
[22:37] <Kissaki> wiki is in attachements here..
[22:37] <Kissaki> ah ok
[22:37] <Kissaki> Example: The current time is 21:37:30Z (UTC).
[22:37] <Kissaki> In the Default time zone , this would be displayed as 23:37:30+0200.
[22:37] <Kissaki> but that's a user setting anyway, right?
[22:38] <LarstiQ> it is, but it should have it's affect on the timeline
[22:38] <LarstiQ> Kissaki: so it's timezone is correctly set to +0200, good
[22:39] <LarstiQ> Kissaki: can you compare `bzr log` and `bzr qlog` time?
[22:40] <Kissaki> hm does list the last svn commit as 12:51 +0000 on log, and 14:51 in qlog.
[22:40] <Kissaki> but 15:51 on trac
[22:41] <Kissaki> oO
[22:41] <LarstiQ> sounds to me like there is a computer configured 1 hour off
[22:42] <Kissaki> hm
[22:42] <Kissaki> that would be 2 then
[22:42] <Kissaki> as mine is correctly +2
[22:42] <LarstiQ> could be
[22:43] <Kissaki> ^^
[22:43] <Kissaki> don't think so...
[22:43] <LarstiQ> I'm out of ideas as to how debug it further atm
[22:43] <Kissaki> it seems to loose 1hour when pulling svn commits from svn server
[22:44] <LarstiQ> jelmer: ^^
[22:44] <LarstiQ> Kissaki: might be a bzr-svn bug filed about that already
[22:44] <Kissaki> you filed about that already?
[22:44] <LarstiQ> no
[22:44] <Kissaki> but strange that it doesn't lose 2 hours then...
[22:45] <Kissaki> maybe it's the summer-savings time
[22:45] <LarstiQ> Kissaki: true, not all systems switch that automatically
[22:45] <Kissaki> well, I'll continue to travel through time then :) (well, it's not even me but them...)
[22:45] <Kissaki> trac does have it correctly after all
[22:45] <Kissaki> thanks anyway
[22:46] <LarstiQ> Kissaki: if you do find bzr-svn is at fault, and no one else has filed a bug like it, I think jelmer would be rather interested in how to reproduce this situation
[22:47]  * LarstiQ has to go to bed
[22:47] <Peng_> LarstiQ: Good night.
[22:47] <LarstiQ> Kissaki: I'd be interested in hearing how things fare for you. Good luck in any case!
[22:47] <LarstiQ> Peng_: thanks, you too.