[01:15] <Tsmith__> test
[01:16] <Tsmith> Alright.  I have set up a bzr repository via bzr+ssh:// on a remote server.  On my local box, I have grabbed a branch of that via $ bzr get.  I have made a lot of changes to this branch locally and now want to update the remote repository.  How do I do this?
[01:16] <LeoNerd> bzr push   to the same URL
[01:17] <Tsmith> u know... that's actually pretty damn nice
[01:17] <Tsmith> i can have revision control and have my local dev box be totally fucked and not affect the root but still get updates
[01:18] <Tsmith> i've used CVS/SVN for 10 years now, but let me tell you, two days of using bzr has totally rocked my world
[01:18] <Tsmith> is there a way to do bzr diff on the remote repository banch?
[01:22] <Tsmith> ALRIGHT! so bzr push on local and bzr update on remote
[01:22] <Tsmith> LeoNerd, thank you very much
[01:39] <Peng> Tsmith: Generally, the repo on the server shouldn't have a working tree.
[01:39] <Tsmith> whats that mean?
[01:40] <Tsmith> > confused <
[01:40] <Tsmith> i come from the SVN world
[01:40] <Peng> Tsmith: You shouldn't keep a working tree on the remote side. (Bazaar branches can operate with or without one.)
[01:40] <Tsmith> woah
[01:40] <Peng> Tsmith: (Y'know, the working copy.)
[01:41] <LeoNerd> A branch stores history.
[01:41] <LeoNerd> A working copy is a checkout of some point in that history, possibly with local modifications, likely because you want to commit that as a new point in history
[01:41] <Peng> Tsmith: Push to e.g. /srv/bzr/foo on the server, then if you need a working copy on the server, "bzr branch" or "bzr checkout" that location.
[01:41] <Tsmith> so i think i have a "working copy" on the server in /var/bzr/sbconsultants; and i access this *remotely* via $ bzr get bzr+ssh://hopeseekr@server/var/bzr/sbconsultants
[01:41] <LeoNerd> A repository on a server generally only needs the former.. Though nothing stops it having the latter as well
[01:41] <Tsmith> is that right?
[01:42] <Peng> Tsmith: If you really need a working copy there, you can install the push-and-update plugin.
[01:42] <Tsmith> i dont want a working copy
[01:42] <Tsmith> i guess i installed it really wrong
[01:42] <Peng> Tsmith: No. Bazaar uses three things: the repository, which is a big bag of revision data; the branch, which is basically just a list of revisions, and the working tree.
[01:43] <Peng> Tsmith: You should read the user guide or something.
[01:43] <Tsmith> i started the repository on my local dev box, tar gzipped up the entire damn thing, uploaded and uncompressed on the remote server in /var/bzr, deleted my own local copy, and ran the bzr get bzr+ssh:// thing
[01:43] <Tsmith> lol it seems to work tho ;)
[01:44] <Peng> Tsmith: You could've just pushed instead of tarred it.
[01:44] <Tsmith> are the only files on the remote server that are needed in /var/bzr/sbconsultants/.bzr?
[01:45] <Tsmith> it seems there's a .bzr in every branch
[01:45] <Peng> Tsmith: Anyway, to remove the working tree from a branch, run "bzr remove-tree". From the shared repo, also do "touch .bzr/repository/no-working-trees" so that new branches won't be created with working trees.
[01:45] <Tsmith> alright
[01:46] <Tsmith> now i have a db.php.~1~
[01:46] <Tsmith> ; is that some internal backup or important?
[01:49] <Peng> Tsmith: It's a backup, made when bzr would be overwriting/deleting a file you've modified.
[01:49] <Peng> Tsmith: E.g. when you run "bzr revert some-file.txt".
[01:49] <Tsmith> ahhhhh
[02:35] <bob2> wonder why --no-trees osn't the default
[02:36] <Odd_Bloke> bob2: Because then whenever you branched while doing normal development, you'd also have to checkout.
[02:36] <Odd_Bloke> Which would be inconvenient and unnecessary.
[02:39] <bob2> hm, I just meant changing the default for the init-repo command
[02:41] <bob2> would that still have that effect?
[02:52] <jelmer> bob2: repositories are meant to be "just a storage optimization". having the behaviour of creating a working tree when creating a new branch depend on whether you are in a repository is inconsistent with that
[02:55] <bob2> ahh, right
[03:03] <Odd_Bloke> bob2: If you wanted to make that the default behaviour, you could use an alias.
[03:03] <bob2> oh, I have
[13:40] <hgr> have a feature-request for qbzr, is this the rigth place? :)
[13:42] <bob2> prbably better to file a nug so it doesn/t get forgotten
[13:42] <bob2> er, bug
[14:55] <Warddr> What makes bazaar better then SVN?
[14:56] <jelmer> Warddr, you may want to have a look at http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html
[15:23] <Warddr> And how can I save a location for bazaar? Now I get this error:
[15:23] <Warddr> warddr@warddr-laptop:~/ludem-ward-test$ bzr merge
[15:23] <Warddr> bzr: ERROR: No location specified or remembered
[15:25] <bob2> "bzr merge --remember someurl" will remember someurl
[15:26] <Warddr> ty bob2, sounds logical
[15:28] <Warddr> bob2, ty, it's working
[16:54] <LaserJock> anybody know how to flush the disk cache from CLI?
[17:00] <jelmer> LaserJock, 'sync'
[17:00] <LaserJock> jelmer: ah, thanks. seems simple enough :-)
[17:01] <LaserJock> seems I need to redo all my performanc tests
[17:17] <nysin> I've been trying to use bzr gconflicts and it's nice and all except that it seems to save things back into foo.{BASE,THIS,OTHER} without touching the actual file in which the conflict is to be resolved. Is this the case?
[17:17] <nysin> (since that's how it launches the 3rd party merge/diff viewer)
[18:18] <LaserJock> so I'm thinking of an easy way to time a big merge on the linux tree
[18:19] <LaserJock> if I put 2.6.0 into a repo, then import 2.6.25.1
[18:20] <LaserJock> then branch that, import 2.6.25.2 into the branch
[18:20] <LaserJock> then finally merge that back to the main branch
[18:20] <LaserJock> does that sound like a reasonable test?
[18:21] <fullermd> Depends what you're testing.
[18:21] <fullermd> It would merge a fair numbe of files, to be sure.  But only one revision.  And only on a 2-rev history.
[18:22] <LaserJock> fullermd: yeah, that's for sure the weakness of my test
[18:23] <fullermd> The emacs switchover is a good demonstration that vhast improvements in scaling with tree size generally don't bleed over into scaling with history size   :|
[18:23] <LaserJock> but I don't really want to completely convert the entire git repo into bzr and hg
[19:09] <nysin> So if bzr-gtk launches its diff3 program with only the {OTHER,BASE,THIS} filenames, is the intended workflow to perform whatever merges are desired to an arbitrarily chosen file and then copy that file over to the one actually under revision control?
[22:34] <swegner> ﻿Hi all.  I'm starting a new project that I'd like to have hosted on Launchpad, so I'm trying to get used to the bzr version control.  When I have a group of contributors making commits, will they each need their own "branch", or is there a way to register one global "trunk" for the project's developers?
[22:35] <beuno> swegner, you can have a global trunk
[22:35] <beuno> just create a team
[22:35] <beuno> upload the trunk to the team
[22:36] <beuno> and add all the members you want to have access to that team
[22:36] <swegner> that makes sense
[22:36] <swegner> ok, I'm going to get started on that-- thanks for the tip  :)
[22:37] <beuno> swegner, np, and welcome  :)