[01:15] test === Tsmith__ is now known as tsmith === tsmith is now known as Tsmith [01:16] 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] bzr push to the same URL [01:17] u know... that's actually pretty damn nice [01:17] 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] 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] is there a way to do bzr diff on the remote repository banch? [01:22] ALRIGHT! so bzr push on local and bzr update on remote [01:22] LeoNerd, thank you very much [01:39] Tsmith: Generally, the repo on the server shouldn't have a working tree. [01:39] whats that mean? [01:40] > confused < [01:40] i come from the SVN world [01:40] Tsmith: You shouldn't keep a working tree on the remote side. (Bazaar branches can operate with or without one.) [01:40] woah [01:40] Tsmith: (Y'know, the working copy.) [01:41] A branch stores history. [01:41] 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] 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] 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] A repository on a server generally only needs the former.. Though nothing stops it having the latter as well [01:41] is that right? [01:42] Tsmith: If you really need a working copy there, you can install the push-and-update plugin. [01:42] i dont want a working copy [01:42] i guess i installed it really wrong [01:42] 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] Tsmith: You should read the user guide or something. [01:43] 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] lol it seems to work tho ;) [01:44] Tsmith: You could've just pushed instead of tarred it. [01:44] are the only files on the remote server that are needed in /var/bzr/sbconsultants/.bzr? [01:45] it seems there's a .bzr in every branch [01:45] 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] alright [01:46] now i have a db.php.~1~ [01:46] ; is that some internal backup or important? [01:49] Tsmith: It's a backup, made when bzr would be overwriting/deleting a file you've modified. [01:49] Tsmith: E.g. when you run "bzr revert some-file.txt". [01:49] ahhhhh [02:35] wonder why --no-trees osn't the default [02:36] bob2: Because then whenever you branched while doing normal development, you'd also have to checkout. [02:36] Which would be inconvenient and unnecessary. [02:39] hm, I just meant changing the default for the init-repo command [02:41] would that still have that effect? [02:52] 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] ahh, right [03:03] bob2: If you wanted to make that the default behaviour, you could use an alias. [03:03] oh, I have [13:40] have a feature-request for qbzr, is this the rigth place? :) [13:42] prbably better to file a nug so it doesn/t get forgotten [13:42] er, bug [14:55] What makes bazaar better then SVN? [14:56] Warddr, you may want to have a look at http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html [15:23] And how can I save a location for bazaar? Now I get this error: [15:23] warddr@warddr-laptop:~/ludem-ward-test$ bzr merge [15:23] bzr: ERROR: No location specified or remembered [15:25] "bzr merge --remember someurl" will remember someurl [15:26] ty bob2, sounds logical [15:28] bob2, ty, it's working [16:54] anybody know how to flush the disk cache from CLI? [17:00] LaserJock, 'sync' [17:00] jelmer: ah, thanks. seems simple enough :-) [17:01] seems I need to redo all my performanc tests [17:17] 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] (since that's how it launches the 3rd party merge/diff viewer) === `6og is now known as Kamping_Kaiser [18:18] so I'm thinking of an easy way to time a big merge on the linux tree [18:19] if I put 2.6.0 into a repo, then import 2.6.25.1 [18:20] then branch that, import 2.6.25.2 into the branch [18:20] then finally merge that back to the main branch [18:20] does that sound like a reasonable test? [18:21] Depends what you're testing. [18:21] It would merge a fair numbe of files, to be sure. But only one revision. And only on a 2-rev history. [18:22] fullermd: yeah, that's for sure the weakness of my test [18:23] 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] but I don't really want to completely convert the entire git repo into bzr and hg === bigdo5 is now known as bigdo2 [19:09] 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] 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] swegner, you can have a global trunk [22:35] just create a team [22:35] upload the trunk to the team [22:36] and add all the members you want to have access to that team [22:36] that makes sense [22:36] ok, I'm going to get started on that-- thanks for the tip :) [22:37] swegner, np, and welcome :)