[00:20] <xif> lifeless: what "problematic limitations"?
[00:34] <ecognito> Hi.  Would anyone have any code that hooks post-push to send an email?
[00:35] <beuno> ecognito, maybe you're looking for: https://launchpad.net/bzr-email/
[00:37] <ecognito> That sends an email on a commit.  I want it on the push, so it will notify the members of the group automatically when there is something useful to pull.
[01:16] <lifeless> xif: no versioning of symlinks,directories,renames[hg does renames now, but by copy+delete semantics]
[01:27] <lifeless> abentley: ping
[01:28] <lifeless> abentley: I'm seeing the index as being about 30% of runtime using my branch to checkout --lightweight bzr.dev with no accelerator tree
[01:28] <lifeless> abentley: where is your branch again; I'll merge it in and test
[01:48] <jkakar> I'm really impressed that bzr detects criss-cross merges and helps me figure out how to make completing the process as painful as possible.  bzr rocks!  It sure does! :)
[02:03] <lostylost> where abouts is the main configuration for bzr kept?
[02:04] <lifeless> bzr --version will tell you
[02:04] <lostylost> thanks! sorry in a hurry, otherwise I would have scoured more
[02:24] <lostylost> Is anyone here familiar with the email post commit hook plugin?   the post_commit_to setting is put in bazaar.conf?
[02:24] <lifeless> 'bzr help email' should describe how to configure it
[02:25] <lostylost> Yeah, I tried that, I am quite new to bzr, it says to set the post_commit_to setting but not exactly where. I am thinking in bazaar.conf?
[02:26] <lifeless> yes, bazaar.conf or locations.conf
[02:26] <lostylost> thanks
[02:26] <lifeless> docs.bazaar-vcs.org has complete documentation on the config files
[02:30] <ubotu> New bug: #190096 in bzr "doc use of revert --forget-merges to create commits without history" [Undecided,New] https://launchpad.net/bugs/190096
[02:30] <lostylost> thanks lifeless
[02:45] <abentley> lifeless: http://code.aaronbentley.com/bzr/bzrrepo/fast-iter-files-bytes
[02:47] <abentley> lifeless: that branch caches nodes, and when I accidentally disabled the cache, it seemed about a second slower.
[02:48] <lifeless> abentley: caches nodes?
[02:48] <lifeless> abentley: do you mean an additional cache on top of the index?
[02:48] <abentley> Yes.
[02:48] <abentley> It shouldn't help but it seems to.
[02:48] <lifeless> abentley: ok; I'm doing a quick-fix to reduce index queries, I hope it will fit well with what you;ve done (its about a 30-minute thing), I'll post it in a minute
[02:51] <lifeless> basically just tweaking get_components_positions to only ask the index once per component rather than 3 times
[03:00] <abentley> lifeless: I don't think I use get_components_positions at all.
[03:01]  * igc food
[03:06] <skvidal> I have an unbound branch I'm working on
[03:06] <skvidal> is there any way to have bzr push just go to wherever I branched it from?
[03:06] <skvidal> so I don't have to specify where?
[03:07] <abentley> skvidal: You only have to specify the first time.
[03:07] <abentley> It remembers after that.
[03:07] <skvidal> okay
[03:07] <beuno> skvidal, and if you want to overwrite the current one, just add   --remember
[03:07] <lifeless> abentley: _get_component_positions was teh core workhorse before your patch; I'd hope you either refactored or deleted or something :)
[03:07] <skvidal> thanks
[03:07] <lifeless> abentley: anyhow its doing a test run across all tests then I -> send and forget
[03:09] <abentley> lifeless: Not yet, because so far, I'm only supporting packs.
[03:11] <lifeless> k, well I'll look at your patch shortly, I may have some feedback for you ;)
[03:15] <abentley> So far, the best time I've gotten out of yours is 4.554, which is at least 500 ms faster than my best time without indices.
[03:16] <abentley> without your index fixes, I mean.
[03:16] <lifeless> well thats promising
[03:16] <abentley> Sorry, 50ms, not 500
[03:16] <lifeless> pushing a new version now
[03:17] <lifeless> up to 1/2's the number of IO round trips
[03:17] <abentley> ooh, 4.514
[03:18] <abentley> 4.429
[03:18] <lifeless> revno 3221 is pushed
[03:21] <abentley> I don't see it.
[03:22] <lifeless> abentley: on people ?
[03:22] <abentley> No, on bazaar.launchpad.net
[03:22] <lifeless> it will be up to 6 hours behind
[03:22] <abentley> but, but, it supports the smart server.
[03:23] <lifeless> rather useful huh? But the lp guys tell me that I won't get a button to tell it to mirror till > lp 2.0 at least
[03:23] <lifeless> pack streaming is ~=. The index stuff is however much nicer in bzr+ssh now
[03:23] <lifeless> I should get bzr+http up on my people branches.
[03:23] <lifeless> give the sysadmins something todo.
[03:23] <lifeless> :>
[03:24] <lifeless> seriously speaking I will need a place to test that if we ever want it to come up to scratch speed wise
[03:24] <abentley> Why do you prefer it?
[03:24] <lifeless> I make new branches continually
[03:24] <abentley> (and yes, I've got it now.)
[03:24] <skvidal> abentley, beuno: thank you for the help - it does work happily now
[03:25] <lifeless> Until we fix the cost of uploading new branches to the hosted site, it is prohibitive for me
[03:25] <lifeless> that index fix is sent to the list as well
[03:25] <abentley> Hmm.  Maybe I have bzr+ssh on rookery...
[03:26] <lifeless> wooo
[03:26] <lifeless> 4.6 seconds!
[03:26] <lifeless> that knit index fix shaves 1 second user time
[03:28] <abentley> The best time I've seen with 3221 is 4.589
[03:28] <lifeless> wall clock I have 5 seconds down from 6 seconds
[03:28] <lifeless> (I'm using the patch I just sent to lp with my rev 3221
[03:28] <lifeless> I'm going to merge your branch now and compare
[03:29] <abentley> 4.461
[03:29] <abentley> ooh, 4.380
[03:30] <abentley> So wall clock time is ~4.4 - 4.7
[03:31] <lifeless> your branch gives me 4.4 wall clock
[03:31] <lifeless> so 6 seconds bzr.dev, 4.4 yours and my range-map, 5 range-map + knit-index-tweaks
[03:31] <lifeless> I'm looking at your branch's code now, and callgrinding
[03:32] <lifeless> oh, it has storage in it :(. I'll go reply to that thread now.
[03:32] <abentley> I'm following your (kind, (file_id, version)) suggestion for the index_keys, and that seems to work nicely.
[03:33] <lifeless> cool
[03:33] <abentley> lifeless: I don't insist on Storage for this code, but I still think it's the right idea for other reasons.
[03:33] <abentley> Anyhow, that's why I said not to freak when you saw it.
[03:34] <lifeless> abentley: ok! I'm not freaking, just fixing up a procrastinated mail-reply I owe you :)
[03:48] <abentley> lifeless: bzr+ssh kinda works on rookery.  Gives bzr: warning: unsupported locale setting
[03:48] <abentley>   Could not determine what text encoding to use.
[03:52] <spiv> LANG=C "fixes" that.
[03:57] <mwhudson> spiv: do your magic thing to pull plz
[03:57] <mwhudson> sorry, push
[03:59] <abentley> spiv: why does get_data_stream_for_search return a single read function for the results?
[04:00] <abentley> It seems to require buffering stuff in a StringIO
[04:00] <abentley> I would have thought something more like what you did with containers.
[04:03] <lifeless> abentley: a comment on the approach; rather than a lot of static methods, did you consider just generalising *KnitIndex's responsibilities to be for (type, id) rather than just a single id ?
[04:04] <lifeless> abentley: a fairly trivial adapter could implement that for normal Knits on top of the current _KnitIndex
[04:04] <lifeless> abentley: and the current KnitGraphIndex could actually become simpler and faster by not doing StripPrefixAdapter usage
[04:05] <lifeless> abentley: actually, skipping the (type) and just allowing a file_id into the keys would probably be cleaner in the short term with the way that maps to a single logical index
[04:06] <abentley> I guess I hadn't really thought about it.
[04:07] <abentley> I was focusing on making Storage present an apparently-unified index for all item kinds.
[04:08] <lifeless> in this particular case if you called 'Storage' 'MultiKnit' or something
[04:09] <lifeless> and had it implemented in knit_repo and pack_repo as appropriate, I think it would fall out quite nicely; particularly if we move our callers to it.
[04:10] <lifeless> ok, your branch is definately nice and fast
[04:10] <lifeless> get_build_requirements is 33% for me
[04:10] <abentley> Sure, I can rename it.
[04:11] <lifeless> 20% in _read_and_parse
[04:11] <abentley> And I do want to support it for both knit_repo and pack_repo.
[04:11] <lifeless> abentley: (well I meant renaming and not having all those static methods :))
[04:12] <lifeless> 18% in _parse_regioj
[04:12] <lifeless> I'll focus on _parse_region
[04:12] <abentley> Nice.
[04:13] <lifeless> 15% in _parse_lines though, perhaps its time for a C extension there
[04:13] <lifeless> abentley: if you could eyeball my knit speed patch, its quite a win in and of itself
[04:14] <abentley> Those static methods are a bit thorny for me, because I'm using them in ways I wouldn't want to use a KnitGraphIndex.  But I can't remember the details ATM.
[04:14] <lifeless> right, this is what I mean about generalisation
[04:14] <lifeless> KnitIndex can be unchanged
[04:15] <lifeless> MultiKnitIndex creates new knit indices and calls onto them
[04:15] <lifeless> GraphKnitIndex gets renamed to something like LegacySingleGraphKnitIndex
[04:15] <lifeless> a new GraphKnitIndex is one that supports a single key space from the get-got
[04:16] <lifeless> and KnitVersionedFile gets its api changed, and is given the new index type directly
[04:16] <lifeless> this avoids needing to get at internal index methods from your super-efficient class, because it is now part of the structure rather than an outsider
[04:17] <lifeless> (paraphrase: roll the Knit api forward to be more powerful(
[04:20] <abentley> I see what you're saying.
[04:21] <abentley> Man, I have got to find the time to work on my gtk merge-directive-applying tool.
[05:02] <abentley> lifeless: The next key bit I see for my branch is ensuring it doesn't consume all available memory.
[05:02] <abentley> After that, compatibility with standard knits.
[05:03] <c1|freaky> it's a  pitty the trac plugin doesn't really work
[05:03] <c1|freaky> :(
[05:04] <johnny> well.. trac doesn't work very well with distributed vcs
[05:04] <johnny> atm
[05:04] <johnny> it only works really well with subversion, it was written too tightly around it
[05:04] <johnny> they are working on it
[05:04] <johnny> for the next version of trac
[05:04] <abentley> Yeah, it's got too many wrong assumptions about the APIs a VCS might use.
[05:05] <johnny> any of the plugins are hacks
[05:05] <c1|freaky> is there anything like trac for bzr?
[05:05] <c1|freaky> or is there at least some kind of webinterface to browse files etc.?
[05:05] <johnny> launchpad?
[05:05] <johnny> hehe
[05:05] <abentley> For example, in order to tell you what files have changed, it gets the two versions and compares whether they've changed.
[05:05] <abentley> Instead of just asking the VCS which files have changed.
[05:05] <johnny> ii'm sure there is a way to browse files for bzr ...
[05:06] <johnny> gotta be
[05:06] <spiv> c1|freaky: there are a couple of web interfaces to browse files in bzr branches.
[05:06] <Debolaz2> Is the launchpad code available?
[05:06] <c1|freaky> no
[05:06] <c1|freaky> closed source
[05:06] <spiv> c1|freaky: there's loggerhead, which launchpad uses (e.g http://codebrowse.launchpad.net/~bzr/bzr/trunk)
[05:06] <johnny> not yet
[05:06] <johnny> maybe some day
[05:06] <c1|freaky> and what is the best webinterface for bze repos?
[05:07] <spiv> (And loggerhead is open source.)
[05:07] <c1|freaky> ok im having a look at it
[05:07] <spiv> There's also the "bzr webserve" plugin, but I think loggerhead looks nicer.
[05:07] <johnny> in the cases where they are multiple options, very rarely is one better than the other to everybody
[05:07] <johnny> at that point it's usually a matter of opinion
[05:07] <johnny> just like all open source stuff :)
[05:07] <c1|freaky> spiv: where can i download it
[05:07] <johnny> pull it via bzr
[05:08] <c1|freaky> how to do that?
[05:08] <c1|freaky> ill search for it
[05:08] <johnny> there we go :) that's a good answer :)
[05:08] <spiv> c1|freaky: https://launchpad.net/loggerhead
[05:08] <c1|freaky> thank you
[05:08] <c1|freaky> :)
[05:08] <johnny> ok.. grocery store time
[05:09] <abentley> lifeless: I bb:approved your patch.  Guess the list is slow.
[05:09] <lifeless> abentley: cool; I'll submit it now. I'm about to head trainward
[05:10] <lifeless> any changes needed - my mail client is closed
[05:10] <abentley> No.
[05:10] <lifeless> thanks
[05:14]  * lifeless waves
[05:16] <Peng> There's also bzrweb.
[05:16] <Peng> And I think another.
[05:16] <freakyy> hi im c1|freaky
[05:16] <freakyy> umm
[05:16] <freakyy> im trying to run loggerhead but it says
[05:17] <freakyy> ImportError: No module named bzrlib
[05:17] <freakyy> someone knows what is missing?
[05:17] <mwhudson> um
[05:17] <mwhudson> is bzr installed?
[05:17] <freakyy> yea
[05:17] <mwhudson> are you running loggerhead with the same python as the one that has bzr installed?
[05:17] <freakyy> one moment
[05:19] <Peng> freakyy: There's also bzrweb, and I think another one.
[05:20] <freakyy> hm i have to set up every repo with loggerhead
[05:22] <mwhudson> you can point it at a directory of branches
[05:24] <freakyy> i can't find the port setting
[05:24] <freakyy> :\
[06:05] <freakyy> http://bzr.code-1.de everything working now :D <-- loggerhead with http proxying :D
[06:05] <etteyafed> Anyone know of a good CGI interface for bzr?
[06:05] <etteyafed> Like to manage a bzr tree from a web server.
[06:05] <etteyafed> Absolutely must be GPL/FOSS though.
[06:06] <bob2> https://launchpad.net/loggerhead is a viewer
[06:08] <etteyafed> That would be useful. I also need a management interface though. I was planning on writing it in house but if there is something available I would like to consider it and at least look at the design.
[06:10] <bob2> what do you mean by management?  there's things like bundlebuggy and cart.
[06:10] <etteyafed> I could probably Adapt logerhead for that really.
[06:11] <etteyafed> I mean doing things like bzr add, commit, resolve, merge, update, etc, and be able to configure default arguments for each of the commands.
[06:11] <etteyafed> but with a web interface
[06:12] <etteyafed> so no shell login is needed
[06:12] <freakyy> does cart yet have a developer team or a website?
[06:13] <etteyafed> Obviously there are other things on the server side and security side that I have already implemented to make something like that work for multiple users in a secure way. Do cart or bundlebuggy do those things (the bzr mgmt stuff)
[06:14] <etteyafed> I am really just looking at getting bzr vcs functionality to our users without making them login to the system and learn all the commands.
[06:14] <bob2> it kinda sounds like a cms is more waht you want
[06:17] <etteyafed> no this is for the vcs of source code
[06:17] <etteyafed> code maintained by users for users on a remote server
[06:18] <etteyafed> so bzr is the way to go I think, or some other vcs, but I prefer bzr
[06:18] <bob2> there's olive, a tortoise*-alike
[06:19] <etteyafed> olive is, as you know, run locally
[06:19] <etteyafed> and not on the server, nor is it cgi
[06:19] <etteyafed> it is in GTK I am pretty sutre
[06:19] <etteyafed> sure*
[06:20] <etteyafed> Trust me. I know what I need. I just don't know if it already exists in some form or not.
[06:24] <etteyafed> I think cart might work very well if I add some things here and there, but I am not sure since I have not really looked at it yet.
[06:30] <Peng> How would one work with that? How would you edit files?
[06:35] <Debolaz2> How does bzr deal when I want to make a lot of small changes, but then later squash them into a big change for inclusion into the main branch?
[06:36] <etteyafed> Peng: Well you log in, and you then have edit rights to any files that you own and create files in your personal space, project, or in a team space of a team you are a member of. The editing is done in a JS test editor or in an editor of your choice that can be configured in your profile and when you are done the edited version of the file would be sent back to the server. In order to use a local editor you would obviously need to 
[06:37] <etteyafed> Peng: And the bzr commands are available to any user to use on any branch that they have rights to.
[06:44] <Peng> etteyafed: Your first line ended with "In order to use a local editor you would obviously need to".
[06:44] <etteyafed> Peng: install a launcher script that will collect the edited file from the a temp dir (like /tmp in a *nix)
[06:45] <etteyafed> must have gotten cut off by the server
[06:45] <Peng> IRC line length is limited.
[06:45] <etteyafed> Sure is
[06:45] <Peng> Your client should've been smart enough to break it for you.
[06:45] <etteyafed> My client knows that and should have cut it sooner
[06:46] <etteyafed> but that limit varries form server to server and apparently pidgin has decided not to ask the server and just assumes a "resonable default" or something
[06:47] <etteyafed> but I have found that even in the case of line limits you are something like -40 chars in reality. not sure why, but I had that same problem with an irc bot.
[07:59] <AfC> Yikes! What on earth does
[07:59] <AfC> bzr: ERROR: Pack 'f8987ec441dc91318f8fd1a99e6c5f42' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0xb74a174c>
[07:59] <AfC> mean?
[08:00] <fullermd> I s'pose it could mean you found a hash collision.
[08:02] <AfC> [was during an attempted `bzr push bzr+ssh://...`, both sides bzr 1.1]
[08:02] <fullermd> You could probably repack the far side to get rid of it...
[08:02] <AfC> repack?
[08:03] <fullermd> Yeah, assuming it's not all in one pack already.  That would get rid of the colliding name.
[08:03] <fullermd> Not sure why you'd end up with it in the first place, short of a real collision (which is impressively unlikely).
[08:03] <fullermd> But it's a workaround.
[08:04] <AfC> I kicked off a `bzr check`. We'll see if it reports anything, and then I'll try again.
[08:05] <AfC> Hm. Second attempt at push "just worked" (and quickly, too).
[08:06]  * AfC wonders if there was network damage somewhere along the way, and what the likelihood of repository damage is.
[08:07] <igc> night all - have a good wekkend
[08:12] <etteyafed> like brain damage, its hard to tell ;)
[08:12] <AfC> heh
[08:12] <etteyafed> unless its profound
[08:12] <etteyafed> then its all screwed anyway
[08:13] <AfC> Well, I did a full branch to a blank repository and have the test suite running. That's a reasonably astute check.
[08:17] <etteyafed> yeah. figure you have X revisions times x files of x bytes in size / packets transmitted  blah blah blah - 3.14 = the chance of any one revision getting messed up
[08:17] <etteyafed> by some unknown network data coruption
[08:18] <etteyafed> that is in its own rather unlikely
[08:18] <etteyafed> because malformed packets are generally disgarded
[08:19] <etteyafed> so I like bzr how about you :). yeah I am nuts and going to bed.
[08:28] <mtaylor> etteyafed: there is corruption at the nic level
[08:28] <mtaylor> etteyafed: which sadly, I have actually seen multiple times this last year
[08:28] <mtaylor> etteyafed: essentially, the NIC checksum offloading was lying :)
[08:30] <etteyafed> that is just terrible. I have not come across such things I am happy to say, at least not that I knew of. I have had to replace bad cards though.
[08:33] <fullermd> It's unpleasantly un-rare, especially with cheaper NIC's.
[08:40] <AfC> I just tried adding a branch to launchpad, and it bombed out with «The URI scheme "bzr" is not allowed.» That's famous.
[08:40] <AfC> Pfft. So much for bothering to add data to that thing.
[08:41] <mwhudson> AfC: for a mirrored branch?
[08:44] <AfC> mwhudson: yeah. I was just trying to Do The Right Thing as I happened across the fact that I had previously registered a branch there some time ago. So I thought I'd add a few more, and boom. Most impressive.
[08:45] <mwhudson> AfC: hmm
[08:45] <mwhudson> AfC: file a bug, i guess
[08:52] <appcine> Hi. I'm currentöy using svn as the single developer on multiple projects. I need to work in a centralized environment. Why should I switch to  bazaar? I branch a lot in svn, which is a pain and I hear you've fixed. And refactor a lot, but I think svn rename works ok.
[08:54] <fullermd> Why do you need to work in a centralized environment?
[08:55] <Debolaz2> appcine: Bah, just mentioning branching and subversion in the same sentence gives me nightmares. :(
[08:55] <fullermd> (That's not an attempt to be combative, BTW; it's to quantify the real constraints.  'centralized environment' means too much and too little most of the time)
[08:58] <bialix> hdima: privet
[08:59] <hdima> hi
[09:03] <appcine> fullermd: Well, because I'm behind a firewall
[09:03] <appcine> fullermd: I need a drop-point
[09:04] <appcine> fullermd: so, that's what I need more than a CVCS :)
[09:06] <fullermd> OK.  Which way is that a problem?  Do you mean "I need a repo outside the firewall, so I can see it from somewhere else", or "I need a repo inside the firewall, 'cuz I can't see out"?
[09:09] <appcine> I have three client and a svn server today. The three clients are on separate networks with no portforwarding possibilities and they all have dynamic ips. So, I need _something_ to use as a drop-zone or whatnot, be it a svn server, ftp http :)
[09:10] <fullermd> OK.  Well, you can use a central branch and checkouts, which will give you pretty much the svn workflow (just better dealing with branches etc, and faster ops since checkouts have a local cache)
[09:10] <fullermd> You could step back from that a bit and use regular branches, but push to the central server "when necessary" (if you can quantify that 'when necessary' well enough, and trust people to do so)
[09:11] <fullermd> And of course you can mix and match; use checkouts on a central branch, but also make local branches for stuff.
[09:13] <appcine> Ok, sounds good to me :) By the using the svn workflow, what am I missing really?
[09:13] <fullermd> Well, you're missing all the power and flexibility of ultimate-distribution full-mesh style workflows.
[09:13] <fullermd> You're also missing the irritation and frustration of ultimate-distribution full-mesh style workflows    ;)
[09:14] <fullermd> The key thing to grab onto is that it's not all-or-nothing.  You can have a SVN-style workflow that everybody BUT you uses, and you can still work more distributed yourself, just tieing into the central branch when you have stuff to land.
[09:14] <fullermd> And you can change over time how you do stuff; the way you set it up initially doesn't have to tie you in forever.
[09:16] <appcine> Ok
[09:16] <etteyafed> is there a way I can push to a branch so that that branches working tree is updated and maybe commited at the same time?
[09:16] <fullermd> So you can set it up pretty much like you use svn now, and worry about changing one thing at a time.
[09:17] <appcine> fullermd: Sounds about perfect
[09:17] <appcine> fullermd: The reason I'm here ist hat people say that branching is so easy in bzr. How do oyu do it in bzr?
[09:18] <appcine> Well, branching and that people say it's renaming facilities are better, even though I've never eally had any problems witht hat in svn (unless in a huge refactoring session adn you forgot to branch :)
[09:19] <etteyafed> appcine: I use bzr branch FROM_LOCATION [TO_LOCATION]
[09:19] <appcine> etteyafed: Then cd TO_LOCATION and hacka awy?
[09:19] <appcine> away
[09:20] <etteyafed> appcine: but there are other ways of accomplishing basically the same thing
[09:20] <Odd_Bloke> etteyafed: To update the working tree, look in to the push-and-update plugin.  I'm not sure what you mean by 'commited at the same time'...
[09:20] <etteyafed> Odd_Bloke: Well it doesn't need to be commited, and that is actually kindof wrong
[09:20] <etteyafed> Odd_Bloke: But this plugin is it part of bzr?
[09:21] <fullermd> appcine: Right, just that.  'bzr branch trunk work_on_foo ; cd work_on_foo ; <work>'
[09:21] <Odd_Bloke> etteyafed: You'll have to install it yourself, but it is a bzr plugin.
[09:21] <fullermd> appcine: Now, that creates a local branch.  If I want to make that an additional central branch that I can work lockstep with other people on, I'd push it up to the central server, then use 'reconfigure' to change my local branch into a checkout of it.
[09:22] <etteyafed> I am looking for it at this very moment
[09:22] <appcine> fullermd: So I kep working on trunk and refactor in work_on_foo, then I merge them how? bzr merge work_on_too trunk?
[09:22] <fullermd> appcine: You _could_ directly create a remote like "bzr branch bzr+ssh://server/foo bzr+ssh://server/bar", but I don't think there's any optimization of that, so it would probably copy all the info across your network twice   :|
[09:23] <appcine> Ah
[09:23] <Odd_Bloke> etteyafed: https://code.edge.launchpad.net/bzr-push-and-update
[09:23] <fullermd> appcine: Well, depends on which way you merge.  If you're done with 'foo', you can "cd trunk ; bzr merge ../work_on_foo", check the result, and commit it.
[09:23] <appcine> Ok
[09:23] <fullermd> appcine: Or if you've done a lot of trunk, and you've got more left to do on foo, you can do it the other way; be in foo and "bzr merge ../trunk" to resolve the differences then (and save yourself trouble later), then keep going on.
[09:24] <fullermd> And if foo is multi-part of course, you can merge it into trunk as in the first example, then keep working on it and merge again later.
[09:24] <appcine> Sounds easy enough. I'm printing the manual now, so I shouldn't exhaust you .. but there is one last thing I'm wondering about :)
[09:24] <appcine> Does bzr have anything like svn hooks?
[09:25] <appcine> Like, If I commit to the server, can it automatically do something?
[09:25] <fullermd> Yes and no and much better and sorta.   :)
[09:25] <fullermd> Currently, none of the hooks fire on the server side; they're all client-side.  We've just had (or are still having) a thread on the list about moving that forward.
[09:25] <fullermd> So I'd expect movement on that over the next few months.
[09:26] <appcine> Ok
[09:26] <appcine> I'll give it a run for its money then :)
[09:26] <appcine> Thanks a lot for the introduction
[09:27] <fullermd> No prob   :)
[09:30] <etteyafed> Odd_Bloke: How do I install that?
[09:30] <etteyafed> just user the script?
[09:32] <Odd_Bloke> etteyafed: Assuming you're on a *NIX, "bzr branch http://bazaar.launchpad.net/~bzr/bzr-push-and-update/trunk ~/.bazaar/plugins/pushandupdate"
[09:32] <etteyafed> yeah linux
[09:33] <etteyafed> heh. I branched to my home dir.
[09:33] <etteyafed> ill just mv it
[09:33] <etteyafed> maybe
[09:33] <Odd_Bloke> Move it to something along the lines of "~/.bazaar/plugins/pushandupdate".
[09:34] <Odd_Bloke> The "pushandupdate" can change, but needs to be a valid Python module name.
[09:37] <etteyafed> Odd_Bloke: Sweet. Thanks. Now I can don't have to bounce back and forth between terminal windows to get a change in the main tree.
[09:40] <etteyafed> Server hooks would be awesome. but I need sleep, so I guess ill dream about them.
[09:41] <Odd_Bloke> etteyafed: Glad I could help. :)
[09:47] <garyvdm> ls
[09:47] <fullermd> . ..
[10:04] <Dejan> hello
[10:04] <Dejan> guys, is it possible to download bzr documentation in some form?
[10:05] <Dejan> i mean ok, i can mirror it via wget
[10:05] <Dejan> but it is strange the documentation cannot be downloaded (at least i could not find the place) in some form of chunked html or pdf
[10:05] <Dejan> :)
[10:05] <Dejan> bzr is excellent
[10:06] <dato> Dejan: it *should* come bundled with your packages, debian's and ubuntu's eg. ship it
[10:07] <dato> Dejan: if you installed from source, you can *build* the html, using docutils
[10:07] <Dejan> dato, i am getting the source at this moment
[10:07] <Dejan> it is kinda slow for some reason
[10:08] <Dejan> (bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev is on 30% and it is so for 20min)
[10:08] <Dejan> i guess ktorrent is the reason :)
[10:09] <dato> Dejan: I'm afraid it's just slow, but the doc also comes in the tarballs
[10:10] <Dejan> dato, i tried to find tarballs on the website
[10:10] <Dejan> bazaar-vcs.org
[10:10] <Dejan> no doc packages there
[10:11] <Dejan> to download
[10:11] <Dejan> i must check if they have some "request for enhancement" place
[10:11] <Dejan> so i can file a request :)
[10:12] <dato> Dejan: the tarballs have a doc/ subdirectory
[10:15] <Dejan> ah, i have it!
[10:15] <Dejan> in /usr/share/doc/bzr-1.1
[10:15] <Dejan> :)
[10:15] <Dejan> sorry mate, i was lazy to check that
[10:17] <Dejan> actually it is even better than i thought
[10:17] <Dejan> it is in asciidoc format
[10:18] <Dejan> so i can build documentation myself
[10:18] <Dejan> great
[11:05] <jjrojo> somebody can help me for start using bazaar?
[11:14] <turnip> Hiya. Is there any simple way to do this... I want to pull some vendor code into my project but still be able to update it. Their repository is subversion - so I want to import the code into my bzr branch, and then occasionally update it from their repository?
[11:20] <Zindar> bzr-svn is what you want
[11:22] <turnip> ok cool. so say I have a working copy at "myproject", and I do "bzr pull svn://whatever myproject/vendor". Then can I later do "bzr update myproject/vendor" and it will get the latest changes from the upstream svn?
[11:23] <cammoblammo> I'm running bzr 1.0 and I want to upgrade the branch format. Which is the best/safest/recommended at this stage?
[11:24] <jelmer> cammoblammo: Just running "bzr upgrade" will upgrade the branch to the default format
[11:26] <cammoblammo> jelmer: Hmm, I did that and I got "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data."
[11:26] <jelmer> cammoblammo: Ah, this is a branch created by bzr-svn you're trying to upgrade?
[11:26] <jelmer> cammoblammo: try "bzr upgrade --rich-root-pack"
[11:27] <cammoblammo> jelmer: Cool. Are any of the formats preferred on low memory (32MB) machines?
[11:28] <jelmer> I think packs are more efficient wrt memory usage, but 32Mb may still be a little bit low
[11:28] <cammoblammo> jelmer: Ha, that seems to be working.
[11:28] <cammoblammo> jelmer: It seems to go okay, I've just got to give it time!
[11:30] <cammoblammo> jelmer: Great, that seems to have worked. Thanks!
[11:31] <jelmer> cool
[11:31] <jelmer> looks like we need to file a bug about upgrade not choosing the right default
[11:33] <cammoblammo> jelmer: I'm using the debian sid version. Should I file a bug there?
[11:34] <jelmer> cammoblammo: yes, please do
[11:40] <turnip> Further to my question above, I am having trouble working out how to do what I want to do... I am really looking for something like Piston: http://piston.rubyforge.org/ which works with bzr
[11:40] <dato> ooooooh
[11:40] <turnip> In other words, I want to "mount" an upstream checkout in my branch and be able to update it
[11:41] <dato> bzr shell allows normal commands like vi and ls
[11:41] <fullermd> turnip: If it were me, I'd keep a pristine vendor branch and merge it in as necessary.
[11:41] <jelmer> turnip: this is something that you can do with by-value nested branches
[11:42] <turnip> jelmer: can you point me to some docs for that please?
[11:43] <jelmer> I'm not sure there are any
[11:43] <turnip> :)
[11:43] <jelmer> I've got to go for a bit, will be back in ~30 minutes
[11:43] <jelmer> I'll see if I can find some docs on it then
[11:44] <turnip> jelmer: thanks
[11:44] <turnip> for now I'll try branch-and-merge way fullermd described
[11:45] <fullermd> By-value nested branches are roughly the same thing, just with a little more magic.
[11:45] <fullermd> (at least, AIUI)
[11:46] <cammoblammo> jelmer: I've reported that bug to Debian. In answer to your question, the branch was originally an svn repo that came to me via bzr-svn.
[11:51] <turnip> fullermd: this <http://jelmer.vernstok.nl/blog/archives/164-Bazaar-and-Subversion-nested-tree-support.html> seems to be what I want, if only it explained how it worked ;)
[11:52] <dato> abentley: I guess I'm late for the party, but... thanks a lot for `bzr shell`
[11:57] <johnny> anybody seen cvsps-import hang on wait4() right after it says it is generating a dump file?
[11:58] <turnip> fullermd: I have done a "bzr branch ~/svnupstreamproject" and then a "bzr merge ~/svnupstreamproject ~/myproject/vendor/upstreamproject" but it says: bzr: ERROR: Repository KnitPackRepository('~/myproject/.bzr/repository/') is not compatible with repository KnitRepository('~/svnupstreamproject/.bzr/repository/') - any ideas?
[11:59] <turnip> (it wasn't those commands exactly but you get the idea)
[11:59] <fullermd> Yes, bzr-svn projects use a rich root format, so you'll need to move your project over to one too, to merge in the code.
[11:59] <fullermd> Try upgrading it to rich-root-pack.
[12:00] <fullermd> Also, I don't think merge can take a second arg for the target; you'll have to bzr mv the files into whatever subdir manually after the merge.
[12:01] <fullermd> (that's the part the nested tree stuff should magicize)
[12:03] <turnip> fullermd: Yep I realised that afterwards. I was cd-ing into the myproject/vendor/upstreamproject before running merge. However now I get: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified."
[12:04] <fullermd> Right.  Merge figures out the common base to work from, but those branches have no common base, so you need to tell it manually.
[12:04] <fullermd> Add "-r0..-1", to tell it "from the beginning, to the end"
[12:07] <turnip> fullermd: Thanks for your help. I've gotta go eat now but I'll be back in a bit :) cheers
[12:48] <johnny> hmm..
[13:37] <alf_makina> hi
[13:41] <johnny> hmm, having trouble with the cvsps imports again
[13:41] <johnny> it just hangs on
[13:41] <johnny> Creating cvsps dump file: infoshopkeeper_bzr/staging/infoshopkeeper.dump
[13:47] <garyvdm> Hi - I would like to implement my own WorkingTree format. Is there some doc that specifices what methods need to be implemented?
[13:48] <garyvdm> I want to implement this: http://bazaar-vcs.org/DraftSpecs/RestingTree
[13:48] <johnny> garyvdm, prolly the python src..
[13:48] <johnny> if it is properly docced
[13:48] <johnny> i haven't checked
[13:48] <johnny> i'm still new to bzr
[13:49] <alf_makina> when I dot a bzr add, the file is not added
[13:50] <alf_makina> although it's shown to be added if I do a dry-run
[13:51] <luks> is it listed as added in bzr st?
[13:51] <alf_makina> no
[13:51] <alf_makina> it's in unknown
[13:52] <luks> and if you do 'bzr add FILE', what does it say?
[13:52] <alf_makina> nothing
[13:55] <alf_makina> to init my branch I've made a bzr co svn+ssh://...
[13:55] <luks> ouch
[13:55] <luks> no idea how does that work on a svn checkout
[13:56] <alf_makina> :-(
[13:58] <jelmer> alf_makina: "bzr st" lists no files at all?
[14:00] <alf_makina> jelmer: it lists all files as unknown
[14:00] <alf_makina> all unversionned files
[14:00] <jelmer> how exactly did you create this branch?
[14:00] <alf_makina> bzr co svn+ssh://...
[14:01] <jelmer> ok, the fact that it comes from svn shouldn't matter
[14:01] <alf_makina> I'm new to bzr and try to use bzr for local commits and then push to the svn repo
[14:01] <jelmer> have you tried to use "bzr add <absolute-path>"
[14:01] <alf_makina> well, I've just tried bzr upgrade --dirstate-with-subtree
[14:02] <alf_makina> and it seems to have broken my repo :-/
[14:02] <jelmer> Broken it how?
[14:02] <alf_makina> commit failed
[14:02] <alf_makina> and bzr st shows that everything has been deleted
[14:03] <jelmer> what version of bzr are you using?
[14:04] <alf_makina> 1.1
[14:04] <jelmer> and bzr-svn?
[14:04] <alf_makina> 0.4.6
[14:05] <alf_makina> ok, I've revert the upgrade
[14:05] <alf_makina> and tried a bzr add with full path, it's not better
[14:06] <jelmer> You can't revert the upgrade, you'll have to recheckout
[14:06] <alf_makina> there's a .bzr_backup directory created
[14:07] <alf_makina> I've deleted the .bzr a put back the .bzr_backup
[14:10] <abentley> dato: you're welcome
[14:15] <alf_makina> jelmer: it seems to work for other files
[14:15] <alf_makina> I check this
[14:16] <jelmer> alf_makina: The file doesn't happen to be in the ignore list?
[14:16] <alf_makina> no, I've already check this
[14:18] <jelmer> sorry, no idea then
[14:19] <alf_makina> it's weird, I've several java file which can't be added :-/
[14:20]  * Mez converts 17035 svn commits to bzr with "branch"
[14:21] <Mez> gonna take about 5 hours :(
[14:23] <jelmer> alf_makina: Please ask on the mailing list
[14:23] <fullermd> It goes faster if you have a prime number of commits.
[14:24] <jelmer> hey Mez
[14:24] <Mez> jelmer, hey
[14:24]  * jelmer is still amazed by the amount of knowledge fullermd has present
[14:24] <fullermd> You don't have to keep it all present if you just make it up as necessary   ;>
[14:24] <Mez> fullermd, ....
[14:24] <Mez> lol
[14:25] <fullermd> If there's a prime number of commits, see, it gets perfect distribution of the hash lookups...
[14:25] <Mez> jelmer, am I doing it right though ?
[14:25] <fullermd> (you can't just make up some random thing.  It's gotta sound plausible.)
[14:25] <jelmer> fullermd: :-)
[14:25] <Mez> fullermd, lol
[14:25] <jelmer> Mez: should be, yes
[14:25] <jelmer> Mez: Be sure to run it inside a shared repository though
[14:25] <jelmer> Mez: And use the python-subversion from hardy, that doesn't have the memory leak..
[14:25] <Mez> "inside a shared repository" ?
[14:26] <jelmer> bzr init-repo --rich-root-pack foo
[14:26] <Mez> where foo is?
[14:26] <jelmer> cd foo && bzr branch svn://svn.bla../trunk trunk
[14:26] <jelmer> where foo is a not yet existing directory
[14:26] <Mez> ah, I'm not pulling from the svn server
[14:26] <Mez> I'm going from a local co of a branch in a svn server
[14:26] <Mez> (downloading 4Gigs isnt going to be good)
[14:27] <jelmer> that has the same effect
[14:27] <jelmer> it'll just check what svn url the local co is using
[14:27] <Mez> jelmer - reallY?
[14:27] <jelmer> since svn checkouts don't contain any history
[14:27] <Mez> there doesnt seem to be that much traffic being used though
[14:28] <jelmer> it's quite efficient
[14:28] <Mez> what does the --rich-root-pack do anyways ?
[14:29] <jelmer> Mez: It's the format to use
[14:29] <Mez> its not an option listed in the bzr help init-repo though
[14:30] <jelmer> Mez: It's only in bzr >= 1.0
[14:30] <Mez> 0.90.0
[14:30] <Mez> :(
[14:30] <jelmer> ouch
[14:30] <jelmer> in that case, use --dirstate-with-subtree
[14:30] <Mez> lol
[14:31] <jelmer> however, 1.0 or 1.1 is going to be a lot faster
[14:31] <Mez> tis ok, 1.0.1 is in backports
[14:31] <jelmer> https://bugs.edge.launchpad.net/gutsy-backports/+bug/184386
[14:31] <ubotu> Launchpad bug 184386 in gutsy-backports "Please backport bzr-svn (0.4.5-1) from Hardy" [Undecided,Fix released]
[14:32] <Mez> ...
[14:32] <jelmer> you want the backport for bzr-svn as well, otherwise bzr-svn breaks
[14:33] <Mez> I thought i was just using a checkout!
[14:33] <CardinalFang> 1.1 speaking to 1.0 "bzr+ssh", "branch", How can I find out what "bzr: ERROR: Generic bzr smart protocol error: Generic bzr smart protocol error: bad request '54'" means?
[14:34] <Mez> jelmer - ah - it was only backported 28 minutes ago
[14:34] <Mez> hasnt made it to the archives yet
[14:35] <fullermd> CardinalFang: You sure that's 1.1, and not a bzr.dev?
[14:36] <CardinalFang> Eh, no, I'm not sure.  It probably is dev, around snapshot time.
[14:36] <CardinalFang> So, don't use dev.  Got it.
[14:37] <fullermd> There is (was) an interop issue with .dev against older servers.  It was fixed...   a day or two ago?
[14:37] <jelmer> Mez: Ah, whoops. Is there something like an "incoming" directory for ubuntu?
[14:38] <Mez> jelmer... everything gets put through the buildds... so it depends
[14:40] <Bloged> Good day....
[14:41] <Bloged> I'm using bzr as an central repository
[14:41] <Bloged> But this morning my colleagues PC crashed during committing a branch
[14:42] <Bloged> Now committing to that branch is impossible
[14:42] <jelmer> Bloged: what error do you get when committing?
[14:42] <Bloged> bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'as_dict'
[14:43] <Bloged> And a traceback
[14:43] <jelmer> Please file a bug report including the traceback
[14:43] <jelmer> I'm also happy to ahve a look now
[14:43] <Bloged> Ok will file bug
[14:43] <jelmer> but this is also definitely a bug
[14:45] <Mez> jelmer, hasn't even hit waiting for buildds yet
[14:45] <Mez> https://edge.launchpad.net/ubuntu/gutsy/+builds?build_text=bzr-svn&build_state=all
[14:45] <jelmer> ah, so that's where status for packages can be followed
[14:45] <jelmer> thanks
[14:46] <Mez> jelmer, one of the palces
[14:46] <Mez> places
[14:46] <Mez> https://edge.launchpad.net/ubuntu/+source/bzr-svn/ = another
[14:53] <Bloged> Jelmer and anyone intrested in the bug:
[14:53] <Bloged> https://bugs.launchpad.net/bzr/+bug/190204
[14:53] <ubotu> Launchpad bug 190204 in bzr "After PC crash during commit, commit impossible in that branch" [Undecided,New]
[14:59] <Peng> Doh, I just wanted to say something to CardinalFang.
[15:00] <Peng> Bloged: Try 'bzr break-lock sftp://branch/url'.
[15:00] <ubotu> New bug: #190204 in bzr "After PC crash during commit, commit impossible in that branch" [Undecided,New] https://launchpad.net/bugs/190204
[15:01] <Peng> Bloged: The lock file exists but is empty, which bzr doesn't handle well, since the only way it can happen is if the computer crashes or something.
[15:01] <Peng> Bloged: You're the second person to experience this this week.
[15:01] <Peng> I guess bzr is getting popular among people with unreliable servers? ;)
[15:02] <Bloged> Peng: break-lock doesn't work
[15:03] <Bloged> Or unreliable OS's
[15:03] <Bloged> Since it was the workstation that crashed...
[15:04] <Bloged> Should I remove the lock file?
[15:05] <Peng> Hold on.
[15:07]  * Peng plays hold music.
[15:10] <Peng> Ok, the mailing list message really didn't say anything very useful.
[15:12] <Peng> I don't know if it's safe to manually delete the lock yourself. bzr break-lock might help make other things consistent too.
[15:12] <Bloged> Yep but break-lock fails too
[15:12] <Bloged> The lock directory is empty BTW
[15:14]  * Peng shrugs.
[15:14] <Peng> There are multiple lock directories, FWIW.
[15:15] <Bloged> Ok....
[15:15] <Peng> A quick look suggests break-lock doesn't do anything else, but I'm not sure.
[15:16] <Peng> You could back it up and then try deleting broken-looking locks.
[15:16] <Peng> I really don't know how careful you need to be here.
[15:18] <Bloged> I can't find any dirs with lock information in them :$
[15:31] <ubotu> New bug: #190209 in bzr "branching lp: uris does not use system http proxy" [Undecided,New] https://launchpad.net/bugs/190209
[16:20] <vinc456> hi, i'm running on debian stable and currently have Bazaar (bzr) 0.11.0)'
[16:21] <vinc456> installed. I'm planning to use bzr for a group project at school and am wondering if I will have any issues if my classmates are running on 1.1
[16:23] <beuno> vinc456, you are likely to have many problems if you're using 0.11. I would suggest to upgrade yourself to 1.0+. I believe it's available in backports for debian
[16:23] <vinc456> i see, thanks
[16:26] <beuno> :D
[16:28] <garyvdm> I'm running this code: http://pastebin.org/18707
[16:28] <garyvdm> I would expect it to create the lock dir at mybranch/.bzr/remotetree
[16:29] <garyvdm> but it is creating it at mybranch/remotetree
[16:29] <garyvdm> Why is this?
[16:29] <jelmer> garyvdm: I think you're specifying root_transport
[16:29] <jelmer> rather than transport
[16:31] <garyvdm> ok - let me try use bzrdir.get_branch_transport()
[16:39] <garyvdm> bzrdir.transport works. Thanks jelmer
[16:40] <ubotu> New bug: #190221 in bzr "bzr commit should sanitize input arguments on case-insensitive filesystem" [Medium,Confirmed] https://launchpad.net/bugs/190221
[17:01] <ubotu> New bug: #190229 in bzr "SubversionException on bzr branch" [Undecided,New] https://launchpad.net/bugs/190229
[17:44] <abentley> garyvdm: I think that would not be a WorkingTree, because you don't need/want to support commits.  The interfaces you need to support is the
[17:44] <abentley> Tree interface, which is in bzrlib/tree.py, and is tested in bzrlib/tests/tree_implementations
[19:31] <ubotu> New bug: #190271 in bzr "hgimport crashes with a weird error: LookupError: data/wigner/articulo_wigner17/12/2007.tex.i: no node 0db46aa6c98e8b6b5f97c988d98bb17fb8b08c2f" [Undecided,New] https://launchpad.net/bugs/190271
[20:08] <fbond> Hi, is it possible to merge several different revisions from a remote branch and have them appear as separate revisions, with no single "merge revision" owning them all?
[20:08] <fbond> Do I simply cherry pick each revision, one at a time?
[20:11] <fbond> Or, I guess rebase would do, too ... ?
[20:16] <Odd_Bloke> fbond: Cherry-picking each revision would work.
[20:16] <Odd_Bloke> I've not had much experience with rebase, but I don't think it's what you're looking for.
[20:17] <fbond> Hmm.  rebase seems to have done the right thing, actually...
[20:56] <SlimeyPete> Hi. I've not used bazaar before. I'm trying to push a branch but am getting a "Permission denied (publickey)" error.
[20:57] <SlimeyPete> ah, hang on, found the problem
[21:04] <vinc456> hi, i'm running on debian stable and just installed a backported version of bzr 1.1. The previous version of bzrtools is not compatible and each time i use bzr I get the error 'Bzrtools is not up to date with installed bzr version 1.1.0.candidate.1.'
[21:04] <vinc456> can i turn off this message without uninstalling the bzrtools package?
[21:18] <lifeless> abentley: I woke up with a clear explanation of what about storage feels wrong; its about layering basically, and I think we can probably find some layer that is sensible for writing some higher level stuff in; but much higher level stuff just won't vary at the same point
[21:19] <lifeless> abentley: I'll reply to the thread with more verbiage when I'm awake and not runnin around trying to buy a dishwasher
[21:19] <abentley> Okie.
[21:19]  * abentley is slightly confused, because I thought you'd come around.
[21:20] <abentley> That if it was renamed, and we enhanced Indices...
[21:20] <lifeless> for that specific case; not for the grand plan - and thats part of why I can now explain myself I think
[21:21] <lifeless> as part of this you are very likely onto something and we can find a good compromise
[21:24] <bedros> I'm new to bzr and got a simple question, can I checkout a single file out of a branch in a central repository and edit it w/out copying the whole branch into my hard drive
[21:29] <bedros> anyone awake here?
[21:32] <abentley> You can't check out a single file.  Bazaar versions snapshots of working directories, not single files.  You can extract a single file with "bzr cat", though.
[21:33] <johnny> has anybody here used the cvsps-import. I'm having trouble with with it hanging right after Creating cvsps dump file:
[21:33] <johnny> maybe something is wrongw ith my download?
[21:38] <bedros_> thanks, but here's the scenario I have, if I create a branch for a collection of family photos, and decided to edit a single photo on my Mac, I want to check out a single photo edit it and comit it. I don't have room for the entire photo collection on my mac
[21:39] <bedros_> do you guys think there's a plugin or API I could use to checkout  a single file. or that's not possible with the architecture of bazaar
[21:41] <johnny> it's not possible with any of this gen of systems i bet
[21:41] <johnny> i knowi's not possible with monotone
[21:42] <johnny> git can do partial checkouts i think , but you still get the whole working tree
[21:42] <bedros_> I'm familiar with perforce and I could do just that perforce server. I just checked subversion, and it's also not possible to check out a single file
[21:42] <johnny> perforce isn't known for good design tho
[21:45] <bedros_> I could do "export" or "cat" as someone suggested to get the content of a file,
[21:47] <johnny> but that is just that file without versioning
[21:47] <bedros_> yep
[21:52] <abentley> bedros_: It's 2/3 practicality and 1/3 philosophy.
[21:52] <abentley> Practicality is, it's easy to do something half-assed, but really hard to get right.  Especially considering things like merging.
[21:54] <abentley> Philosophy is, when you're versioning source code, you should test your code.  And how can you test it properly if you don't check it all out?
[21:56] <johnny> i ended up getting my cvs download via scp, i hope that doesn't cause any problems
[22:00] <bedros_> thanks abentley, I found that svn 1.5-dev is going to support single file checkout; there's also discussion about bzr supporting partial checkout
[22:10] <Symgeosis> I'm new to Bazaar. I'm trying to merge somebody else's branch into trunk but I keep getting the error "nothing to do" any idea what I'm doing wrong? There are certiainly revisions that have been made to the other branch that have not been made to trunk.
[22:14] <Symgeosis> Some help on merging two branches would be really appreciated. Please.
[22:15] <jearl> Symgeosis: What precisely did you try?
[22:16] <Symgeosis>  bzr merge http://bazaar.launchpad.net/~keith-hughitt/helioviewer/keith
[22:16] <Symgeosis> I'm trying to merge Keith's changes into trunk.
[22:16] <Symgeosis> I'm in trunk's dir so I'm not sure what I'm doing wrong.
[22:18] <jearl> Symgeosis: Are you sure you haven't already merged :)
[22:18] <Symgeosis> Yup. I checked the commit logs.
[22:18] <Symgeosis> So I'm really confused.
[22:19] <jearl> Symgeosis: Is your trunk branch available somewhere?
[22:19] <Symgeosis> I think I figured it out. I'm such a noob. =/
[22:20] <jearl> Symgeosis: Good, because I was confused too?
[22:20] <johnny> it's too bad that cvsps doesnt support :pserver: :(
[22:22] <jearl> johnny: As someone that has spent a bit of time converting repositories I am glad that cvsps doesn't support pserver.
[22:23] <jearl> johnny: if your conversion is simple enough that it wouldn't take all day with cvsps you can use tailor.
[22:24] <Peng> Symgeosis: Do "bzr st".
[22:24] <Peng> Symgeosis: (short for "bzr status")
[22:25] <Peng> Symgeosis: You have to commit after merging. If you already performed the merge but didn't commit, it would probably say "nothing to do", but it wouldn't show up in the log.
[22:25] <Symgeosis> Peng, yeah I figured that out thanks. Though now I'm trying to figure out how to fix conflicts. Interesting learning how to use a VCS.
[22:26] <Peng> Symgeosis: Ack, I missed you saying you figured it out.
[22:26] <Symgeosis> Peng, np. Thanks anyways.
[22:26] <Peng> Symgeosis: "bzr help conflicts" has information.
[22:34] <johnny> jearl, if i can figure out tailor :)
[22:34] <Symgeosis> Okay, if this is a really noobish question I apologize, but is there a nice tool (command line or otherwise) that can compare the conflicts and then ask which version you'd like to use?
[22:34] <johnny> jearl, i downloaded the cvs tree via scp -r
[22:34] <johnny> i seem to have all the ,v files, isn't that enough?
[22:34] <Symgeosis> I know I can simply open them both up in a text editor but I was wondering if there was a more streamlined way to merge conflicts.
[22:35] <jearl> johnny: For cvsps you need the CVSROOT directory too.
[22:35] <johnny> i have it
[22:35] <johnny> pretty sure at least
[22:35] <johnny> i see it, and it has ,v files too
[22:35] <jearl> johnny: OK, then you are probably good
[22:37] <johnny> i try to run bzr cvsps-import and it just hangs on Creating cvsps dumpfile:
[22:37] <johnny> i straced it and it's just in wait4()
[22:38] <johnny> i accidentally let it go all night and it hadn't moved
[22:39] <Peng> Symgeosis: There are numerous GUI diff and merge programs.
[22:39] <Peng> Symgeosis: Meld? KDiff3? I dunno, there are a lot.
[22:39] <Symgeosis> Peng, okay. Never worked on a project with other people so this is a whole new can of worms for me.
[22:39] <johnny> the simple diff3 :)
[22:41] <johnny> Symgeosis, make a sandbox branch to test with
[22:42] <johnny> so you can play around with things without screwing up other folks
[22:42] <johnny> good stuff
[22:42] <johnny> Symgeosis, you'll have more politics issues than code issues :)
[22:43] <Symgeosis> Johnny, nah. The team is small and we're all employees so it's whatever the boss decides. =)
[22:43] <Symgeosis> Well, technically, I'm an intern and an employee but until recently I was the only coder as the original coder left before I came on.
[22:49] <johnny> jearl, so any ideas on that?
[22:49] <johnny> do i need a specific cvsps version?
[22:51] <jearl> johnny: check CVSROOT/config and see where the Lockdir is pointed at.
[22:52] <johnny> i have a bunch of other  files in there, but not that
[22:52] <jearl> johnny: I would try and see if you can actually check something out of CVS
[22:53] <johnny> have one :)
[22:53] <jearl> something like 'cvs -d /path-to-cvs co <packagename>
[22:53] <johnny> aha. it's trying connect via ssh
[22:54] <johnny> that obviously won't work
[22:54] <johnny> i thought you meant remote checkout.. definitely have one of those, but not this one
[22:54] <johnny> it's trying to connect to my dir
[22:55] <jearl> johnny: Yeah, you need to try and check something out of your newly created repository that you copied down via ssh
[22:55] <johnny> johnny@beep ~/projects/redemmas $ cvs -d test/ co infoshopkeeper
[22:55] <johnny> ssh: test: Name or service not known
[22:56] <jearl> Do you have a CVS config file that sets a default cvs server or something.
[22:57] <johnny> i have ~/.cvspass and ~/.cvsps
[22:57] <johnny> but i deleted ~/.cvsps
[22:57] <jearl> johnny: I would also try a full path
[22:57] <johnny> hmm.. ok
[22:57] <jearl> johnny: I just tried it on my setup.
[22:57] <jearl> johnny: you need a full path to the cvs repository
[22:58] <johnny> ok, so now i see more
[22:58] <johnny> cvs [checkout aborted]: cannot stat /var/lib/gforge/chroot/cvsroot/cvs-locks/infoshopkeeper: No such file or directory
[22:58] <johnny> obviously that won'to work :)
[22:58] <jearl> johnny: you have a lockdir set
[22:59] <johnny> set how/where ?
[22:59] <johnny> aha.. CVSROOT/config
[22:59] <jearl> johnny: There should be a "config" file in the CVSROOT
[22:59] <johnny> can i remove that safely?
[23:00] <jearl> johnny: you can either comment that line out or you can create the directory.
[23:00] <johnny> it also has SystemAuth=yes
[23:00] <johnny> will that cause any problems?
[23:00] <jearl> johnny: I tend to create the directory because I rsync the CVS stuff and it puts it all back
[23:00] <johnny> yeah.. i dont have remote rsync access
[23:00] <johnny> this is not from my own servers
[23:00] <jearl> johnny: I don't know about SystemAuth, one second
[23:01] <johnny> i'm just glad that they didn't disable scp, otherwise i wouldn't have anything
[23:01] <johnny> the project admin hasn't added me to their project to get the full backup
[23:01] <jearl> johnny: ssh is very handy
[23:02] <jearl> johnny: I think you can comment out SystemAuth too.
[23:03] <jearl> johnny: Basically the idea is to keep trying to check out the project from the local repository, when that works then bzr cvsps-import should work.
[23:13] <johnny> jearl, cvsps needs full path but cvsps-import doesn't
[23:15] <ubotu> New bug: #190324 in bzr "ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'report'" [Undecided,New] https://launchpad.net/bugs/190324
[23:19] <johnny> jearl, ok hopefully i can start playing now :)
[23:20] <johnny> didn't seem to see an option to name the target branch tho
[23:27] <jearl> johnny: cvsps imports ALL branches
[23:28] <jearl> johnny: The main branch will be in branches/HEAD
[23:31] <jjrojo> can anyone explain to me how i make bzr in launchpad
[23:32] <jjrojo> i don't end to understand the help
[23:35] <jjrojo> please, i try to migrate from sourceforge
[23:38] <johnny> ok.. time to get into actually using bzr :)
[23:38] <johnny> thanks jearl
[23:38] <jearl> johnny: My pleasure.
[23:38] <jearl> johnny: I am glad that worked for you.
[23:50] <ubotu> New bug: #190331 in bzr-svn "bzr-svn incorrectly reports "no repository present"" [Undecided,New] https://launchpad.net/bugs/190331