[04:54] <Alex____> new to bazaar, feeling out its capabilities
[04:54] <Alex____> got a question, though
[04:54] <Alex____> I'm building a versioning system for scientific figures
[04:55] <Alex____> and I'd like to extend bzr to handle arbitrary metadata
[05:01] <Alex____> would this be possible via a plugin?
[07:36] <vila> hi all
[10:36] <garyvdm> Hi - How do you specify the no-trees option for a repository after it has been created?
[12:23] <Jc2k> jelmer: just pushed a git-receive-pack replacement that operates on bazaar instead (so push over git+ssh:// should work too)
[12:24] <Jc2k> jelmer: unfortunately it looks like it has to conflict with the one provided by git-core, so might be a packagers nightmare
[12:31]  * Jc2k should check how it behaves under 1.6 (probably calls git receive-pack <git dir> instead of git-receive-pack <git dir>)
[14:00] <jelmer> Jc2k, well, it can use alternatives
[14:01] <Jc2k> jelmer: true. so elegant :]
[14:02] <Jc2k> jelmer: are you still working on the index?
[14:02] <jelmer> no, that's already working
[14:02] <Jc2k> ah, awesome.
[14:03] <jelmer> I finished it last night, but haven't tested it extensively yet
[14:04] <Jc2k> im about to start working on pull/clone in bzr-git
[14:04] <jelmer> Jc2k: pull from bzr into git you mean?
[14:05] <Jc2k> yeah, for git-serve
[14:05] <jelmer> Jc2k, where are you going to store the metadata
[14:06] <CaMason> Anyone know why I'd get a blue screen of ultimate death on Windows Vista when checking out a branch over SFTP?
[14:07] <jelmer> Jc2k, ?
[14:10] <Jc2k> jelmer: hmm, i guess thats not my first priority :]
[14:11] <jelmer> Jc2k: I think it should be :-)
[14:12] <jelmer> Jc2k, you can't do proper pull/clone if you don't have full roundtripping
[14:13] <Jc2k> jelmer: i was going to have a sha1/bzr id db on the server side
[14:14] <Jc2k> but i havent thought too much about it
[14:14] <Jc2k> if i think too much nothing gets done.. :p
[14:15] <jelmer> Jc2k, if you do a sha1/bzr id db map
[14:16] <jelmer> you also have to keep a map for the file ids, text revisions and revision properties
[14:16] <jelmer> otherwise we end up breaking the referential integrity
[14:21] <Jc2k> jelmer: i dont know bzr internals, but the last time i thought about this i was concerned a tree sha might relate to multiple inventories
[14:22] <Jc2k> and it was among the reasons i concentrated on the git side :p
[18:34] <meoblast001> hi
[18:35] <meoblast001> how would a user without ssh pull source using bazaar.. i always forget
[18:35] <meoblast001> is it http?
[18:36] <beuno> meoblast001, yup
[18:36] <meoblast001> ok.. so pulling http://bazaar.launchpad.net/~mysticgalaxies/mox/devel/changes would work?
[18:36] <meoblast001> oops
[18:36] <meoblast001> without that changes par
[18:37] <Peng_> Yes.
[18:38] <Peng_> lp:~mysticgalaxies/mox/devel will use plain HTTP if you haven't run launchpad-login.
[18:38] <meoblast001> k
[18:38] <meoblast001> thanx
[18:40] <Peng_> For that specific branch, you can also use lp:mox as a shortcut.
[18:56] <afdasfadgt> is it possible to merge 2 diffrent projects into one?
[21:13] <AmanicA> hi, I'm trying to implement `bzr missing -r 1..-1`, but it turns out we might need 2 sets of revision specs, one for the local branch and one for the remote branch
[21:14] <AmanicA> so either I must make 2 parameters (is there another command like that?)
[21:16] <AmanicA> or I can maybe use `bzr missing -r 1..-1..2..-2` where the last 2 are upper bounds
[21:34] <asabil> AmanicA: I think having bzr pull --dry-run and bzr push --dry-run would be more intuitive imho
[21:35] <AmanicA> good idea, I havn't thougt of that
[21:35] <burak575> is it possible to merge 2 diffrent projects into one?
[21:36] <AmanicA> I hope I didn't waste my whole 31Dec for nothing
[21:40] <AmanicA> asabil: I love you for solving my problem & hate you for telling me I wasted my whole 31Dec for nothing (and gettind a headache while trying)
[21:40] <AmanicA> :)
[21:40] <AmanicA> thanx though!
[21:40] <asabil> sorry :)
[21:40] <asabil> burak575: what do you mean exactly ?
[21:41] <burak575> i was have a project
[21:41] <burak575> and a project related to it
[21:41] <burak575> but i initialized two of them with bzr init so they are not common ancestors
[21:41] <burak575> how can i merge them into one project?
[21:41] <burak575> like bzr merge project projectDLL
[21:42] <burak575> none of them is sharing any common files but i wanna merge them if possible
[21:43] <asabil> you can check bzr help join
[21:43] <asabil> I haven't used it myself, but I think it is the right tool for your problem
[21:44] <burak575> thanks i am gona try it :)
[21:45] <asabil> burak575: it seems like it requires a specific branch format
[21:45] <asabil> you might want to check the "merge-into" plugin
[21:45] <burak575> yeah it said so
[21:46] <burak575> projectDLL doesn't support rich root data. You can use bzr upgrade on the repository.
[21:46] <burak575> it was replied like this i am gona check merge-into plugin :)
[21:48] <asabil> :)
[21:53] <LarstiQ> burak575: you can also `bzr merge -r 0..-1`
[21:54] <burak575> hmm
[22:26] <AmanicA> asabil: I didn't realise `bzr pull --dry-run` is not implemented yet :(  I see merge has a preview though, but that shows a diff
[22:27] <AmanicA> I'm looking for something like log, so I think your suggestion will work nice
[22:27] <asabil> AmanicA: I was suggesting you implement it :)
[22:28] <AmanicA> I realised that now :)
[22:29] <LarstiQ> hehe :)
[22:29] <LarstiQ> AmanicA: you can still make good of your 31st! :)
[22:29] <AmanicA> no its done forever as of 29 minutes ago :(
[22:30] <AmanicA> r/done/gone/
[22:30] <burak575> yeah same
[22:30] <burak575> what is your gmt zone?
[22:30] <AmanicA> gmt+2
[22:30] <burak575> same .D
[22:31] <LarstiQ> AmanicA: aww, sorry to hear that.
[22:32] <LarstiQ> AmanicA: lets capitalise on the 1st then! ;)
[22:32] <AmanicA> :)
[22:32] <burak575> i was made first 2009 commit on bzr 15 mins ago lol
[22:32]  * LarstiQ will have to wait 30 more minutes
[22:32] <LarstiQ> or move my clock forward, hmm :)
[22:33] <AmanicA> I'm still to depressed to code. and I have a headache now :(
[22:34] <AmanicA> I think I should go sleep it off
[22:41] <AmanicA> I was stupid, I wrote the `missing -r..` backend first complete with unit tests... and then realised the ui wont work nice...
[22:44] <davidstrauss> LarstiQ: Or just find tomorrow's commit using revspec date:tomorrow
[22:44]  * davidstrauss cannot figure out why "tomorrow" is a documented date value for revspec
[22:46] <LarstiQ> davidstrauss: ending slices I'd say
[22:46] <LarstiQ> davidstrauss: always inclusive, no off by ones
[22:46] <LarstiQ> at least, that is my assumption
[22:46] <davidstrauss> LarstiQ: but can't you do that explicitly with a non-date revspec?
[22:47] <LarstiQ> davidstrauss: probably true :)
[22:47] <LarstiQ> if your clock is behind revisions it is a bit harder though.
[22:47] <LarstiQ> davidstrauss: how does date:tomorrow interact with timezones?
[22:47] <LarstiQ> 23:45:04 < theeth> I bet I can sneak in a last 2008 commit after your first 2009 commit :)
[22:47] <LarstiQ> from #blendercoders just now
[22:48] <davidstrauss> LarstiQ: It probably doesn't. I'm guessing everything is UTC.
[22:48] <davidstrauss> LarstiQ: Or do you mean when you specify a time?
[22:49] <LarstiQ> davidstrauss: tomorrow semantics could conceivably include revisions where the local date was 1 day ahead of what you are currently at.
[22:50] <davidstrauss> LarstiQ: That seems horribly flawed
[22:51] <davidstrauss> Relativity aside, it's not a different time there
[22:51] <davidstrauss> The daylight just spans different hours
[22:57] <LarstiQ> davidstrauss: I don't know what the semantics are, but I don't see a natural way out of the local vs global distinction
[22:57] <davidstrauss> LarstiQ: time zones aren't part of data and time data
[22:58] <davidstrauss> LarstiQ: They're presentation adjustments
[22:58] <LarstiQ> davidstrauss: exactly, and that matters for ui
[22:59] <davidstrauss> LarstiQ: Right now, in Jerusalem, it's 2009. That doesn't mean an edit happening there right now happens in my tomorrow.
[23:01] <davidstrauss> LarstiQ: An edit never happens in my tomorrow.
[23:02] <ronny> LarstiQ, jelmer: happy new year
[23:02] <LarstiQ> ronny: thanks, you too :)
[23:02] <LarstiQ> davidstrauss: I understand what you mean.
[23:02] <ronny> oh, well, the others, too ;P
[23:02] <LarstiQ> hehe :)
[23:02] <LarstiQ> jelmer is currently at the Brandenburger Tor if things went well
[23:02]  * LarstiQ is in the c-base
[23:02] <ronny> im at home
[23:03] <davidstrauss> LarstiQ: The only difference is disagreement on how we represent "now"
[23:03] <davidstrauss> LarstiQ: But it's a rather superficial difference
[23:04] <ronny> LarstiQ: hopefully next year i can stay a few days longer
[23:04]  * LarstiQ nods at ronny
[23:05] <LarstiQ> and at davidstrauss :)
[23:05] <davidstrauss> I think it's flawed to store timezones with dates
[23:06] <ronny> since i got no mate any more im too sleepy/lazy to get out
[23:07] <ronny> davidstrauss: its usefull to have them on timestamps, gives a better statistics on the daytimes of commits
[23:07] <LarstiQ> davidstrauss: it makes it easier to answer queries where you are looking for commits you made around a certain time, but have since moved timezones
[23:09] <ronny> i got raubritter-beer
[23:09] <ronny> its dark ^^
[23:09]  * LarstiQ toasts ronny's raubritter with his mate
[23:09] <ronny> prost
[23:13] <LarstiQ> proost
[23:13]  * LarstiQ continues reading MD2 preimage attack paper