[00:26] <zsquareplusc> hm. i can't commit if a completely different file in an other folder is in conflicted state?
[00:44] <zsquareplusc> hm. i can't commit a specific file if a completely different file in an other folder is in conflicted state??
[00:50] <Peng_> jelmer: ping?
[00:52] <jelmer> Peng_, pong
[00:53] <Peng_> jelmer: Little subvertpy bug: subvertpy/__init__.py calls warn() but never imports it. I could file a bug (or send a patch), but since it's really trivial and I'm not sure how you'd want to fix it...
[00:53] <Peng_> (And I don't have a browser open ATM.)
[00:55] <jelmer> Peng_, hmm
[00:55] <jelmer> Peng_, There's nowhere to import from unfortunately
[00:55] <jelmer> I guess I'll just change it to ImportError
[00:57] <zsquareplusc> any hints for my problem?
[00:57] <Peng_> jelmer: Just use warnings.warn()?
[00:57] <Peng_> zsquareplusc: Well, you could resolve the conflict. ;P
[00:58] <Peng_> zsquareplusc: Why are you even trying to commit when another file is conflicted?
[00:58] <zsquareplusc> and when i dont want to? its in a different subfolder
[00:58] <Peng_> zsquareplusc: Doesn't that mean you have an uncommitted merge or someting?
[00:58] <jelmer> Peng_, Ah, wasn't aware of that
[00:58] <jelmer> Peng_, fixed
[00:58] <jelmer> Peng_, thanks
[00:59] <Peng_> jelmer: Thanks for ifxing it. :)
[00:59] <Peng_> Augh, more typoes.
[00:59] <zsquareplusc> Peng_ well, i pulled the branch from a server. that generated the conflicts. that ok. now i want to commit locally one changed file
[01:01] <zsquareplusc> the file i want to commit is not in conflicted state. it just modified
[01:01] <Peng_> Eh, TV to watch. See ya later. :)
[01:01] <Peng_> Good luck.
[01:03] <zsquareplusc> hmm.. major disapointment :(
[01:07] <zsquareplusc> and bzr-gtk isn't working neither :(
[01:15] <zsquareplusc> ok the later was because an older copy of the gtk plugin was found in the .bazaar folder and they were mixed up when running olive-gtk :/
[01:53] <jfroy|work> jelmer: mmmmm, just found out about a repository with 250K revisions. Should be fun to branch from that using bzr-svn.
[02:39] <luke-jr> How do I resolve diverged branches when upstream is svn?
[02:39] <luke-jr> ☺
[02:44] <luke-jr> hrm
[02:44] <luke-jr> only 'bzr dpush' has the problem
[03:31] <bob2> isn't that the point of dpush?
[03:51] <luke-jr> bob2: the point of dpush is to not use metadata
[03:51] <luke-jr> I ended up just using metadata anyway
[03:51] <luke-jr> and that worked fine
[03:52] <luke-jr> <.<
[06:16] <Peng_> Is BB down?
[06:23] <Peng_> "502 Proxy Error" says that it is. :P
[07:15] <Odd_Bloke> Peng_: That has meant yes in the past.
[07:15] <Odd_Bloke> abentley: ^
[07:26] <abentley> Peng_: Fixed
[07:36] <Peng_> abentley: What happened?
[14:06] <crisb> hello, i have built some packages for bzr for AIX - anywhere I can put them?
[14:10] <vila> crisb: Ideally they should end up here: http://bazaar-vcs.org/Download
[14:11] <vila> You should find more info on the wiki itself
[14:14] <fullermd> AIX?  Wow.  That brings back painful memories...
[14:18] <crisb> ;)
[14:18] <crisb> its not exactly speedy for some reason
[14:19] <crisb> unfortunately i had to build most of the deps myself too - so they cant really go on the download page can they?
[14:27] <vila> crisb: at least you can list yourself as a contact for any interested user ? Or explain how you proceed to get there (may be at least fun :)?
[14:27] <vila> crisb: did you succeed in running 'bzr selftest' ?
[14:27] <crisb> hmmm :)
[14:28] <crisb> well it works, but so slow
[14:28] <crisb> 30 minutes and it had not yet done 1000 tests
[14:28] <crisb> i think something is up with either python or bzr itself on aix.
[14:28] <vila> ouch
[14:28] <crisb> im probably to blame as i built python too ;)
[14:29] <vila> how about the C compile ? ;)
[14:29] <vila> how about the C compiler ? ;)
[14:29]  * vila wonders when he will able to make a joke without typo...
[14:29] <crisb> not me, but its the IBM one...so should be fine on this platform!
[14:32] <crisb> bzr rocks takes 3 seconds...
[14:32] <vila> oooouch:
[14:32] <vila> time -p bzr rocks
[14:32] <vila> It sure does!
[14:32] <vila> real 0.08
[14:32] <vila> user 0.06
[14:32] <vila> sys 0.02
[14:32]  * fullermd is perfectly willing to assign blame to AIX for anything and everything.
[14:33] <crisb> indeed fuller, its soooo.........IBM ;)
[14:33] <fullermd> The first system I ever adminned ran aches.
[14:33] <fullermd> That was in another millennium.  It still makes me twitch.
[14:33] <ronny> aches?
[14:33] <vila> crisb: wait, I thought IBM stopped to public ennemy #1 with AIX, or am I mixing with something else ?
[14:33] <fullermd> That's how you pronounce "AIX"   :p
[14:34] <ronny> ah
[14:34] <ronny> hmm
[14:34] <ronny> legacy systems can be a pain
[14:35] <ronny> luckyly im not going to be an admin later
[14:35] <vila> ronny: fullermd never talked about legacy here, I think the system was brand new :)
[14:35] <crisb> sadly its got a good reputation in financial systems!
[14:35] <fullermd> Well, that system would be pretty legacy now   :p
[14:36]  * vila first one was SunOS (not that Solaris gizmo...) :-)
[14:36] <fullermd> If it weren't smashed into a kadnillion tiny bits, stomped into the ground, pissed on, dug up so they could be buried upside-down, had runes scrawled and incantations spoken over...
[14:37] <fullermd> I mean, not that I have any hard feelings toward it or anything.
[14:37] <vila> :-)
[14:37] <crisb> gotta love that man with the dumbells though ;)
[14:37] <ronny> hmm
[14:38] <ronny> i grew ~5 files in my repo every 500 commits
[14:38] <ronny> how does bzr bundle up commits?
[14:39] <fullermd> Sorta kinda log(10)ly.
[14:39] <fullermd> It'll grow ~1 file every thousand commits.  Then ~5 every 5 thousand commits.  ~1 every 10 thousand commits.  etc.
[14:40] <vila> It groups packs at 10, 100, 1000 etc
[14:40] <crisb> would anyone be able to point me in the right direction if I showed the output of bzr rocks --profile-imports from my AIX machine?
[14:41] <vila> Each pack comes with a set of index files .rix revisions, .iix, inventories, .tix texts, .six signatures
[14:42] <vila> crisb: better post it to the mailing list: https://lists.ubuntu.com/mailman/listinfo/bazaar
[14:43] <vila> but bzr rocks may not be the most interesting, it does really the minimum and doesn't involve any of the important parts
[14:44] <vila> crisb: for a start did you build celementtree ?
[14:44] <crisb> python 2.5 - so I dont need to right?
[14:44] <vila> right
[14:45] <vila> pyrex ?
[14:45] <crisb> no, but I built solaris and bzr rocks is like 0.2 seconds
[14:45] <crisb> on roughtly comparable, if not slower hardware
[14:45] <vila> yes, not needed for bzr rocks
[14:46] <crisb> perhaps if bzr rocks is slow then that points to python
[14:46] <vila> crisb: right, start with that
[14:46] <fullermd> Well, something lower in the stack than bzr anyway.
[14:47] <fullermd> ISTM that AIX has always had rather painful fork()'s.  But certainly not 3-seconds-painful on even remotely up-to-date hardware.
[14:48] <vila> time -p python -c 'print "hello"'
[14:48] <crisb> 0.03s
[14:50] <glade88> hi. I checkout from lp:ideatorrent. but as the project doesnt give me write access, I did "bzr push lp:~sayakb/ideatorrent/devel" to create a new personal branch. But http://bazaar.launchpad.net/~sayakb/ideatorrent/devel/files is giving me error
[14:50] <vila> crisb: same here, are you using some mounted file system ?
[14:51] <crisb> nop, all local
[14:51] <glade88> btw, commit done about 45 mins back..
[14:52] <vila> glade88: https://code.edge.launchpad.net/ideatorrent
[14:52] <vila> the branch is empty
[14:53] <vila> try pushing again
[14:54] <glade88> vila: "bzr push lp:~sayakb/ideatorrent/devel" ?
[14:55] <vila> glade88: It should works, yes
[14:56] <glade88> vila: thanks. and what about future commits? "bzr commit -m 'blah blah' lp:~sayakb/ideatorrent/devel"
[14:56] <glade88> sorry, I am too used to subversion I guess :)
[14:57] <vila> glade88: If you want your commits to appear in the remote branch, you should bind your local branch to the remote one with
[14:57] <vila> bzr bind lp:~sayakb/ideatorrent/devel
[14:57] <vila> but push first
[14:59] <glade88> vila: when I bind, will the fact that I checked it out from lp:ideatorrent matter?
[14:59] <glade88> since I didnt bind it with lp:ideatorrent
[15:01] <vila> glade88: no it doesn't matter
[15:01] <vila> the branch you checked out *from and the branch you commit *to* may be (and are here) different
[15:02] <vila> but until you're more familiar with bzr you may want to avoid 'bind' until you better understand what branches are involved when
[15:02] <glade88> vila: cool. push under progress
[15:03] <vila> bind transform your branch in a heavy checkout which is generally what users from cvs and svn want, but it can also be a source of misunderstandings when not working in a true centralized workflow
[15:03] <glade88> to avoid that, can I always "push" to my personal branch ~sayakb/... ?
[15:03] <vila> And here, your're not in a such a workflow because you don't have commit rights in the trunk
[15:04] <vila> glade88: yes, you can push whenever you wnat to publish your changes, which amy not be at each commit
[15:04] <glade88> will that show me diffs on the remote location?
[15:04] <vila> push -v will show you what you push
[15:04] <glade88> but push increments the revision number, right?
[15:05] <vila> bzr missing will show you the revisions you need to pull as well as the revisions you created locally
[15:05] <vila> push with increment the revno of the remote branch, not the local one
[15:05] <vila> s/with/will/
[15:06] <glade88> so what would be the best deal to pull from one branch and commit to another one (with increment in commit revs on both local and remote?)
[15:06] <vila> exactly what you've done so far
[15:07] <vila> bzr branch <upstream>
[15:07] <vila> bzr push <my-version>
[15:07] <vila> when you want to synchronized from <upstream> do
[15:07] <vila> bzr merge <upstream> ; bzr commit -m 'Merging from upstream'
[15:07] <glade88> cool. (as the original project owner would review and merge my revisions to lp:ideatorrent)
[15:08] <glade88> damn, still "pushing" the rev..
[15:08] <vila> 'bzr version' ?
[15:09] <glade88> 1.6.1
[15:19] <vila> glade88: 1.12 is out, try upgrading, what os/version are you using ?
[15:21] <glade88> vila: kubuntu 8.10
[15:21] <glade88> maybe it isnt sybce
[15:21] <glade88> *synced
[15:22] <vila> You may try adding one of the ppas : https://launchpad.net/bzr
[15:22] <crisb> vila - ctypes not built on my AIX python, would that slow anything?
[15:22] <vila> https://launchpad.net/~bzr/+archive will gives you the official releases
[15:23] <glade88> vila: thanks. wil update as soon as the push is complete :)
[15:23] <glade88> (still pushing :( :( )
[15:23] <vila> you're certainly pushing the whole project, more recent bzr versions should allow you to use stacked branches which result in pushing only your additional commits
[15:23] <glade88> ok
[15:24] <vila> That will not be always true, but launchpad should be configured for stacked branches
[15:25] <glade88> yes. true. that is the longest commit I ever did to a repo :)
[15:25] <vila> crisb: ctypes is not installed here either, I think it's more important for windows though
[15:33] <ronny> how can i turn a branch + worktree back to just branch?
[15:34] <vila> ronny: first check you have to modifications pending (bzr st) then 'bzr reconfigure --branch' should do the trick
[15:35] <ronny> hmm
[16:03] <gskelly> Hello, I am just starting to learn bazaar. Is it possible to combine branches from multiple shared repositories into a single branch in a new shared repository?
[16:11] <Lo-lan-do> gskelly: If the branches are related, you can merge back and forth to your heart's delight.
[16:13] <Lo-lan-do> Where they are hosted, standalone or in shared repositories, local or remote, has no influence on the functionality, only on performance and disk space.
[16:24] <gskelly> Lo-lan-do: The repositories were created independently.
[16:25] <gskelly> Lo-lan-do: I created a different repo with a single branch for different aspects of a project, (docs, data, calcs) that really should be a single directory structure in a single branch.
[16:25] <gskelly> Hmmm... I'm new to IRC also :)
[16:31] <Lo-lan-do> "oops"
[19:25] <thrope> so I updated my loggerhead - a recent change coflicted with a hack I had to put in to get the links right, so I thought it would be fixed, but it still seems to be completely broken as standar
[19:30] <thrope> all the links are broken
[19:30]  * Lo-lan-do eyes beuno 
[19:32] <ronny> is there any statistic on how the performance incrases over the versions?
[19:32] <thrope> ah take it all back - I had a trailing slash on server.webpath that was the problem
[19:32] <thrope> sorry for the frustrated tone - its been a long day
[20:56] <nevans> jelmer: ping
[20:56] <jelmer> nevans, pong
[20:56] <nevans> bzr-svn NEWS file says that svn-push => push requires patched version of bzr
[20:56] <nevans> will everything else work with plain old bzr 1.12?
[20:57] <jelmer> nevans, yes
[20:57] <nevans> jelmer: thanks.  :)
[20:57] <jelmer> nevans, (svn-push is also still there, for those who don't have the patch)
[20:57] <nevans> wonderful
[21:01] <nevans> jelmer: weird message: "Upgrade to Subversion 1.5 or higher for faster retrieving of revision properties."  but it only says this when I use the implicit (saved) push/pull location.
[21:02] <nevans> I'm on Ubuntu 8.10.  as far as I can tell, everything svn is at 1.5.
[21:02] <jelmer> nevans, it says that when pulling from a < 1.5 svn server
[21:02] <nevans> ahhh.
[21:02] <nevans> well then, I suppose the weird thing is that it *doesn't* say that when I use an explicit push/pull location.
[21:03] <jelmer> nevans, are you sure you're specifying the same location?
[21:03] <nevans> yep
[21:03] <jelmer> nevans, This is all outside of bzr-svn
[21:04] <jelmer> nevans, so bzr-svn will get the same URL in both cases
[21:04] <nevans> weird.
[21:09] <nevans> jelmer: a noop push now takes 1min (rather than 16 to 20).  not ideal, but MUCH better.  thanks.  :)
[21:10] <jelmer> nevans, cool :-)
[22:07] <chx> is there a way to edit the commit message of some older commit (and it's even pushed to launchpad :/ )
[22:08] <Odd_Bloke> chx: No, revisions are immutable.
[22:09] <chx> ok
[22:09] <chx> i did a fix on a latest commit by first uncommitting it :) but sure.
[22:15] <Odd_Bloke> chx: Uncommitting threw away the old commit, the second commit created a separate commit.
[22:15] <chx> yes, i understand that.
[22:15] <Odd_Bloke> OK. :)