| Tsmith__ | test | 01:15 |
|---|---|---|
| === Tsmith__ is now known as tsmith | ||
| === tsmith is now known as Tsmith | ||
| 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:16 |
| 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:17 |
| 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:18 |
| Tsmith | ALRIGHT! so bzr push on local and bzr update on remote | 01:22 |
| Tsmith | LeoNerd, thank you very much | 01:22 |
| Peng | Tsmith: Generally, the repo on the server shouldn't have a working tree. | 01:39 |
| Tsmith | whats that mean? | 01:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| Tsmith | now i have a db.php.~1~ | 01:46 |
| Tsmith | ; is that some internal backup or important? | 01:46 |
| 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 | 01:49 |
| bob2 | wonder why --no-trees osn't the default | 02:35 |
| 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:36 |
| bob2 | hm, I just meant changing the default for the init-repo command | 02:39 |
| bob2 | would that still have that effect? | 02:41 |
| 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:52 |
| bob2 | ahh, right | 02:55 |
| Odd_Bloke | bob2: If you wanted to make that the default behaviour, you could use an alias. | 03:03 |
| bob2 | oh, I have | 03:03 |
| hgr | have a feature-request for qbzr, is this the rigth place? :) | 13:40 |
| bob2 | prbably better to file a nug so it doesn/t get forgotten | 13:42 |
| bob2 | er, bug | 13:42 |
| Warddr | What makes bazaar better then SVN? | 14:55 |
| jelmer | Warddr, you may want to have a look at http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html | 14:56 |
| 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:23 |
| bob2 | "bzr merge --remember someurl" will remember someurl | 15:25 |
| Warddr | ty bob2, sounds logical | 15:26 |
| Warddr | bob2, ty, it's working | 15:28 |
| LaserJock | anybody know how to flush the disk cache from CLI? | 16:54 |
| jelmer | LaserJock, 'sync' | 17:00 |
| LaserJock | jelmer: ah, thanks. seems simple enough :-) | 17:00 |
| LaserJock | seems I need to redo all my performanc tests | 17:01 |
| 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) | 17:17 |
| === `6og is now known as Kamping_Kaiser | ||
| LaserJock | so I'm thinking of an easy way to time a big merge on the linux tree | 18:18 |
| LaserJock | if I put 2.6.0 into a repo, then import 2.6.25.1 | 18:19 |
| 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:20 |
| 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:21 |
| LaserJock | fullermd: yeah, that's for sure the weakness of my test | 18:22 |
| 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 | 18:23 |
| === bigdo5 is now known as bigdo2 | ||
| 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? | 19:09 |
| 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:34 |
| 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:35 |
| 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:36 |
| beuno | swegner, np, and welcome :) | 22:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!