| johnf | Using fetch logic to copy between CHKInventoryRepository('file:///home/johnf/dev/packaging/bzr/ppa/.bzr/repository/')(<RepositoryFormat2a>) and CHKInventoryRepository('file:///home/johnf/dev/packaging/bzr/bzr_2.1.1-1/.bzr/repository/')(<RepositoryFormat2a>) | 02:39 |
|---|---|---|
| johnf | Should that normally take ages and peg my CPU at 100%? | 02:39 |
| johnf | console has - "Fetching revisions:Get stream source" | 02:40 |
| lifeless | should take a couple minutes | 02:40 |
| lifeless | if you don't have the X extensions it could take longer | 02:40 |
| johnf | Does take 2 minutes | 02:42 |
| johnf | autoppa and builddeb seem to be doing it. Never used to take this long | 02:42 |
| johnf | maybe my extensions are missing | 02:43 |
| johnf | nope I've got them | 02:43 |
| lifeless | there isn't really a good reason to have two repositories there | 02:45 |
| lifeless | bzr init-repo /home/johnf/dev/packaging/bzr | 02:45 |
| johnf | Ahh I think I broke that at some stage | 02:46 |
| johnf | do I need to recheck everything else out or does "magic" happen? | 02:46 |
| lifeless | reconfigure --use-shared-repo or something like that | 02:47 |
| johnf | thanks | 02:47 |
| lifeless | otoh fetching a single rev should be near-instant | 02:47 |
| johnf | lifeless: much better! Thanks | 02:55 |
| offby1 | I just tried to download bzr-explorer, by adding http://ppa.launchpad.net/bzr/ubuntu to /etc/apt/sources.list, and installing via aptitude. But aptitude is refusing to install it: after downloading it, it complains that it's the wrong size. Any hints for how to proceed? | 03:49 |
| wgrant | offby1: You are probably behind a (perhaps transparent) proxy that is caching badly. | 04:04 |
| offby1 | not that I know of | 04:04 |
| offby1 | plain old DSL at home | 04:04 |
| wgrant | offby1: What is the exact error message? | 04:05 |
| offby1 | hold on | 04:05 |
| offby1 | Weird, I can't select the text ... | 04:05 |
| offby1 | E: failed to fetch blahblahblah.deb: Size mismatch | 04:06 |
| offby1 | that shows up in a red "dialog box" in aptitude. | 04:06 |
| offby1 | I'll try the command line | 04:06 |
| offby1 | E: Failed to fetch http://ppa.launchpad.net/bzr-explorer-dev/ppa/ubuntu/pool/main/b/bzr-explorer/bzr-explorer_1.0.0final-0~bazaar1~karmic1_all.deb: Size mismatch | 04:07 |
| offby1 | I downloaded it by hand with "curl -O", and installed with "dpkg -i". Let's see if I vanish in a puff of smoke ... | 04:08 |
| * wgrant checks consistency. | 04:09 | |
| offby1 | seems to work | 04:09 |
| wgrant | offby1: The indices | 04:10 |
| offby1 | ? | 04:10 |
| wgrant | ... match on disk. | 04:10 |
| offby1 | dunno what you're talking about, actually. | 04:10 |
| wgrant | So it's probably a transparent proxy on your Internet connection. | 04:10 |
| offby1 | oh | 04:11 |
| wgrant | Because the archive on ppa.launchpad.net is internally consistent. | 04:11 |
| offby1 | ok | 04:11 |
| offby1 | lemme md5sum the .deb; you tell me if it matches what you see | 04:11 |
| lifeless | what is your ISP | 04:11 |
| offby1 | blarg.net | 04:11 |
| offby1 | 0b9dfdd8673dabb6e7cf8093b595df78 | 04:11 |
| wgrant | bzr-explorer_1.0.0final-0~bazaar1~karmic1_all.deb | 04:12 |
| wgrant | Should be: | 04:12 |
| wgrant | 61266149140843c5bfe91d91309cc24e | 04:12 |
| offby1 | uh oh | 04:12 |
| wgrant | My copy of it matches that. | 04:12 |
| wgrant | And the indices say that. | 04:12 |
| wgrant | So your copy is somehow bad. | 04:12 |
| offby1 | crap | 04:12 |
| offby1 | dpkg --purge | 04:12 |
| offby1 | poo | 04:12 |
| wgrant | Which means that it's not just normal bad caching; it's actually holding a corrupted copy of the file. | 04:12 |
| offby1 | well, thanks for checking. | 04:12 |
| offby1 | I wonder if there's some way I can identify the proxy | 04:13 |
| lifeless | you can sometimes trace it using various 'whats my ip' style cgi scripts | 04:14 |
| lifeless | or checking the returned headers of an http query | 04:14 |
| offby1 | aha | 04:14 |
| offby1 | headers sound interesting | 04:14 |
| SamB_XP | yay firebug! | 04:22 |
| Infl8ableSoulm8 | Just recently was pointed towards the possibility of using bzr and was wondering if it would fit my use case... | 06:33 |
| Infl8ableSoulm8 | I'm in charge of updating configs, plugins, and plugin source code for 9 or so game servers (valve's srcds) | 06:34 |
| Infl8ableSoulm8 | 8 of them run on one windows box, and on of them runs on a linux box in a different location. | 06:35 |
| lifeless | sure | 06:35 |
| lifeless | it should handle that just fine | 06:35 |
| Infl8ableSoulm8 | there are three developers (myself included) and at least two other people who would be modifying the configs or source code for the plugins. | 06:35 |
| Infl8ableSoulm8 | and there would also be binary externsions for the plugin mod that we use | 06:36 |
| Infl8ableSoulm8 | basically, reading about bzr it looks like commits are sort of localish, but somehow there is a main branch? | 06:36 |
| Infl8ableSoulm8 | also, I have never really had any reason to use any sort of vcs before, so I'm basically stumbling around int he dark. | 06:38 |
| Infl8ableSoulm8 | I have a subversion repository<?> set up ont he linux box, but it's just a single project with everything in it. | 06:38 |
| Infl8ableSoulm8 | it would be much nicer to have a different project for each server | 06:39 |
| Infl8ableSoulm8 | but svn is way over my head. | 06:39 |
| fullermd | Commits in bzr go onto whatever the branch in question is (which usually the local one) | 06:39 |
| fullermd | Once made, you can copy the revisions out to any other related branch, in arbitrary topologies (a star with one 'central' branch and a lot of outlying branches is probably the most common, but not the only possible) | 06:40 |
| Infl8ableSoulm8 | so, say you have a few people who are collaborating on one source file for a plugin, does one person change something, commit, then another person update their local branch to further extend the work? | 06:43 |
| Infl8ableSoulm8 | and if so, where is the central branch located if there is no centralized server? | 06:43 |
| fullermd | Well, there are a number of ways you CAN do it. | 06:44 |
| fullermd | There can be a central server. The distinction of the DVCS's versus the centralized ones is that there doesn't HAVE to be. | 06:44 |
| fullermd | The simplest to grasp case is probably using bzr just like it were SVN or another centralized system. You have one central branch somewhere, and everybody makes checkouts of it and works there. | 06:44 |
| fullermd | Then all the commits go to the central branch, and if somebody else has commit'd, you have to 'update' to catch up before you can. | 06:45 |
| fullermd | In this setup, you're basically all sharing a single branch. | 06:45 |
| Infl8ableSoulm8 | ahh, ok. | 06:45 |
| fullermd | The opposite extreme is everybody having their own branch, and no central server. | 06:45 |
| fullermd | In that case, to get Bob's changed, you have to merge from Bob. To get Joe's stuff, you have to merge from Joe. | 06:46 |
| fullermd | Sorta a full mesh. | 06:46 |
| fullermd | (though you don't necessarily HAVE to merge from everyone individually; if Bob merges Joe's stuff, and then you merge Bob's, you get Joe's transitively) | 06:46 |
| Infl8ableSoulm8 | well, the central branch idea is the one that makes the most sense to me, since the idea is that they are all going to immediately be in use by the servers | 06:46 |
| fullermd | That usually just doesn't scale for obvious social reasons past a very few people of course. But it's viable technically. | 06:46 |
| fullermd | What usually happens is somewhere in the middle. e.g., everybody shares (either directly via checkouts, or indirectly via gatekeepers) one central branch, except that they also make new independent branches for "bigger" (hazily defined) changes. | 06:47 |
| fullermd | But you can start out with a single central branch, then branch (haha) out from that later as you find reasons too. | 06:48 |
| fullermd | You're not necessarily hooked in to the configuration you start out with. | 06:48 |
| Infl8ableSoulm8 | well, the person who pointed me this way claims that bzr is a lot easier to set up than svn... | 06:48 |
| Infl8ableSoulm8 | I have no idea how to even add a project to svn :/ | 06:48 |
| Infl8ableSoulm8 | I walked through a crappy tutorial I found somewhere, and really don't understand it very well. | 06:49 |
| fullermd | It is in a lot of ways. Also more flexible in a lot of ways (and less flexible in some, though most would argue that those latter are bad ideas in the first place ;) | 06:49 |
| Infl8ableSoulm8 | I just got it to work eventually. | 06:49 |
| SamB_XP | it's true, bzr is a lot easier to set up ;-) | 06:49 |
| fullermd | It's easier to start small&simple with bzr and then scale it up. svn you have to start scaled up. | 06:49 |
| Infl8ableSoulm8 | well, I would like the idea of having the central server be on my linux box, with the main windows game server box pulling updates from the linux box. | 06:50 |
| Infl8ableSoulm8 | that way everything is available from two seperate datacenters | 06:51 |
| Infl8ableSoulm8 | well, I mean that the running copy is, anyway | 06:51 |
| Infl8ableSoulm8 | but I would also like to have a predefined directory structure that mirrors the structure of each game server | 06:52 |
| Infl8ableSoulm8 | so that I can browse through all the configs and plugins locally, and change a few things as need be, then commit, log into the windows box, and update | 06:52 |
| Infl8ableSoulm8 | and basically get rid of all the annoying filezilla/scp stuff I do now :P | 06:53 |
| fullermd | Sure, you could do that with just having one big branch of the stuff on a central server, and checkouts of it in various places (the Win machine, your workstation, etc) | 06:53 |
| Infl8ableSoulm8 | sweet. | 06:54 |
| fullermd | Note that with default ("heavy") checkouts, the full history is cached locally at each spot. So you'll have N copies of all the data if you need it for recovery. | 06:54 |
| Infl8ableSoulm8 | so, when you go to set it up, how do users work? | 06:54 |
| Infl8ableSoulm8 | there are users that can commit, and other who are read-only, etc? | 06:54 |
| SamB_XP | Infl8ableSoulm8: well, whatever you can do with unix permissions ... | 06:55 |
| Infl8ableSoulm8 | well, like svn has the webdav and ssh deals, but setting up a bunch of users and stuff is where things got hairy with svn. | 06:56 |
| SamB_XP | (but there's no restriction of access to only PART of the tree) | 06:56 |
| fullermd | bzr doesn't itself do any AAA. That's all punted to higher (e.g., ssh) or lower (POSIX perms/ACLs) levels. | 06:57 |
| Infl8ableSoulm8 | what about restriction on a project-by-project basis? | 06:57 |
| SamB_XP | that's pretty easy, yeah, as long as you manage them as totally seperate branches | 06:58 |
| fullermd | Generally each project would be a separate branch. | 06:58 |
| Infl8ableSoulm8 | yeah | 06:58 |
| fullermd | (in separate repos, since you can't effectively hard-limit access at a tigher granularity than that) | 06:58 |
| Infl8ableSoulm8 | because we run several different kinds of game server, and there may cmoe a time when people who have acess to Team Fortress 2 server configs will be a completely separate group of people from people who admin the Day of Defeat or Countrer-Strike servers, etc... | 06:59 |
| Infl8ableSoulm8 | ok, so I guess it's time for the classically windowsy question, is there a flashy simple GUI setup utility to get something like this set up for the central branch on ubuntu? | 07:01 |
| Infl8ableSoulm8 | I mean other thant he apt-get part... I can handle that just fine. | 07:02 |
| Infl8ableSoulm8 | I'm guessing not, if everything is dependent on user permissions :/ | 07:02 |
| fullermd | Well, a "central" branch is no different from any other branch. That's fundamental; the concept of 'central' or 'leaf' is a totally social distinction. | 07:02 |
| fullermd | So you put a branch somewhere, set perms on it appropriately, and tell everybody "that's the central branch" | 07:03 |
| SamB_XP | the GUI isn't going to make it much easier, really | 07:03 |
| SamB_XP | the only reason I use a GUI to make repos or branches is if I'm working in Windows and I don't have a command prompt open in the right place, really ;-) | 07:04 |
| Infl8ableSoulm8 | well, let me see... | 07:04 |
| Infl8ableSoulm8 | so I could just set up the 'client' or whatever you'd consider it, create a few directories and tell bzr that they are a certain branch | 07:04 |
| SamB_XP | then it's easier to just pick the appropriate option of the shell menu rather than opening a cmd.exe, CDing to the appropriate directory, and THEN typing the command | 07:05 |
| Infl8ableSoulm8 | and then give people permission to update/commit? | 07:05 |
| SamB_XP | yeah, basically | 07:05 |
| SamB_XP | and what you call the 'client', I call 'bzr' ;-) | 07:05 |
| Infl8ableSoulm8 | right | 07:06 |
| Infl8ableSoulm8 | :) | 07:06 |
| Infl8ableSoulm8 | so I could just create a directory structure on my linux server in some user directory | 07:06 |
| Infl8ableSoulm8 | and set up a branch in a directory | 07:06 |
| SamB_XP | well, you would want to use a group directory really | 07:07 |
| fullermd | I'd recommend doing it as a throwaway and playing around with it a bit, to see what you'll be doing and how it fits. | 07:07 |
| SamB_XP | that's a good idea, yeah | 07:07 |
| Infl8ableSoulm8 | so would each person with access to it need ssh access to the box? | 07:07 |
| SamB_XP | if you play around a bit first, then you'll have more clue what you're doing ;-) | 07:07 |
| fullermd | ssh access is the simplest choice, yes. | 07:08 |
| Infl8ableSoulm8 | hrmm. | 07:08 |
| SamB_XP | is that a problem ? | 07:08 |
| Infl8ableSoulm8 | this is where not being much of a linux admin gets int he way. | 07:08 |
| SamB_XP | ah, yeah ;-) | 07:08 |
| Infl8ableSoulm8 | well, I don't want to give a bunch of people basically shell access to my box. | 07:09 |
| Infl8ableSoulm8 | and I don't really understand chroot stuff. | 07:09 |
| Infl8ableSoulm8 | which is just a guess at one thing I'd need to know to lock things down for those usrs. | 07:09 |
| SamB_XP | you don't trust unix permissions? | 07:10 |
| Infl8ableSoulm8 | no, the permissions are fine. | 07:10 |
| Infl8ableSoulm8 | I get that. | 07:10 |
| fullermd | Well, you wouldn't necessarily have to use YOUR box as the "central" branch, would you? | 07:10 |
| SamB_XP | true | 07:10 |
| Infl8ableSoulm8 | but I mean, if I give someone ssh access to my server, then they can fire up screen and irssi and idle irc or whatever. | 07:11 |
| SamB_XP | and ? | 07:11 |
| SamB_XP | (though there ARE ways to prevent that) | 07:11 |
| Infl8ableSoulm8 | I don't want them to be able to run random programs, but they obviously will need access to commands like cd or ls | 07:11 |
| fullermd | Well, no, they'd only need to be able to run bzr. | 07:12 |
| SamB_XP | that's true | 07:12 |
| fullermd | They wouldn't be logging in to the box to work, they'd just be accessing the branch over bzr+ssh | 07:12 |
| fullermd | They'd WORK on their OWN systems. | 07:12 |
| Infl8ableSoulm8 | right, so I need to figure out how to make it so a user can tunnel over ssh to use bzr, but not login to get a regular prompt | 07:13 |
| Infl8ableSoulm8 | or shell or whatever | 07:13 |
| fullermd | I think there's some discussion in the docs about it, using key auth. | 07:13 |
| SamB_XP | some kind of "allowed commands" setting for ssh... | 07:13 |
| Infl8ableSoulm8 | heh | 07:26 |
| Infl8ableSoulm8 | the docs say "Using SSH configuration options it is possible to restrict developers from using anything but Bazaar on the server via SSH, and to limit what part of the file system they can access." | 07:27 |
| Infl8ableSoulm8 | and that's it :D | 07:28 |
| Infl8ableSoulm8 | guess I have to browse the ssh docs :P | 07:28 |
| luks | Infl8ableSoulm8: the usual way is using authorized_key to restrict access | 08:10 |
| luks | bzr has a simple shell script in contrib/ that can be used in authorized_keys and gives you even more options | 08:11 |
| === nlisgo_ is now known as nlisgo | ||
| Kamping_Kaiser | can i uncommit trunk-2 ? | 10:47 |
| Kamping_Kaiser | i'd like to redo a change, and uncommiting it seems the easiest way to fix it up. | 10:47 |
| fullermd | Technically, you don't uncommit a rev, you uncommit TO a rev. | 10:51 |
| fullermd | So you can uncommit -2, by going to -3. | 10:52 |
| Kamping_Kaiser | ah | 10:55 |
| Kamping_Kaiser | all becomes clear. thanks. | 10:55 |
| reyman | hello guys | 16:39 |
| reyman | i have a question about repository, if i have two project on launchpad, i make 1 or 2 repository ? | 16:40 |
| maxb | reyman: Usually 2 (just because there's no reason to put both in one), but multiple projects can share a repository if you really want | 17:09 |
| reyman | ok thx maxb | 17:10 |
| fullermd | Of course, on launchpad it's somewhat irrelevant, since you don't get to create repos anyway. | 17:12 |
| === retupmoca` is now known as retupmoca | ||
| === radoe_ is now known as radoe | ||
| lotia | how i do i get the revision number that the bisect plugin has switched to? | 19:11 |
| fullermd | I'd guess either revno or revno --tree. I'm not really sure exactly what bisect frobs. | 19:12 |
| lotia | fullermd: thanks. revno doens't take into account the bisection | 19:13 |
| fullermd | revno gives the revno of the branch. revno --tree gives the revno of the working tree. It's possible that bisect does its work without altering either one, so neither may help. | 19:17 |
| fullermd | I'd guess there's probably a command in the plugin to have it tell you where it is, actually. | 19:17 |
| MattCampbell | What's the status of nested trees? | 19:30 |
| hazmat | jam, thanks for posting the ideas and implementation | 20:11 |
| === mnepton is now known as mneptok | ||
| maxb | lotia, fullermd: bisect uses revert (because update -r didn't exist until recently), so the only place you'll be able to find the bisection revno is in whatever private metadata the bisect plugin is maintaining for itself | 20:28 |
| lotia | maxb and any insight into where it does that? | 20:28 |
| maxb | Sorry, no | 21:12 |
| maxb | I never really used it seriously | 21:12 |
| ianm_ | when someone does a "bzr co --lightweight lp:luz", often a later "bzr update" will say they're at the latest rev, when in fact they're not-- any ideas as to why? | 21:49 |
| ctrlsoft | ianm_: are you sure they didn't do a "bzr branch" rather than a bzr co ? | 21:54 |
| ianm_ | ctrlsoft: yes | 21:55 |
| ianm_ | often I did the original one for them | 21:56 |
| ianm_ | otherwise non-techies following website instructions | 21:56 |
| ctrlsoft | ianm_: are they still bound to the correct upstream branch (bzr info should tell you) | 21:58 |
| ianm_ | hm I'll have to check that when I have access. although the temporary solution has always been to do a fresh checkout, which does get the latest, making me think it should be bound to the correct branch | 21:59 |
| lifeless | moin | 22:09 |
| ctrlsoft | hey lifeless | 22:13 |
| ctrlsoft | lifeless: Is it correct that Bazaar is updating ie.revision for a file but doesn't report that file in tree.iter_changes(parent_trees[0]) ? | 22:14 |
| lifeless | sure | 22:15 |
| ctrlsoft | the file wasn't changed as far as I can tell, why would it's revision attribute be updated? | 22:15 |
| ctrlsoft | lifeless: (I'm relying on iter_changes() reporting all newly introduced (ie.file_id, ie.revision) tuples) | 22:19 |
| lifeless | a merge | 22:19 |
| lifeless | if two trees make the same change in parallel then their branches get merged | 22:20 |
| lifeless | you'll get a no-change merge | 22:21 |
| ctrlsoft | lifeless: ahh | 22:21 |
| ctrlsoft | lifeless: thanks, I hadn't considered that | 22:21 |
| lifeless | also if someone merges and does 'bzr revert file' or 'bzr revert .' you'll also see a no-change merge along one side | 22:21 |
| ctrlsoft | lifeless: there's no way to search VF by sha1 is there? | 22:43 |
| * ctrlsoft wonders why he asks a question he already knows the answer to | 22:44 | |
| jam | ctrlsoft: well, if it is the chk one there is :) | 22:44 |
| jam | but no, you have to check inventories to find shas | 22:45 |
| lifeless | CHK can tell you about no-change merges | 22:52 |
| lifeless | but the regular tree interface can't | 22:52 |
| mtaylor | help: | 23:46 |
| mtaylor | I had some changes in a tree - I put them into a shelf | 23:47 |
| mtaylor | then I did reconfigure-pipeline | 23:47 |
| mtaylor | added a pipe | 23:47 |
| mtaylor | tried to unshelve them | 23:47 |
| mtaylor | and now I'm getting NotImplementedError: <property object at 0x7f41c87d5230> | 23:47 |
| ctrlsoft | lifeless: How would I go about doing that for CHK? | 23:52 |
| ctrlsoft | lifeless: I might implement a fast-path for CHK | 23:52 |
| lifeless | ctrlsoft: check the fetch fast path | 23:56 |
| lifeless | mtaylor: bug filing time | 23:57 |
| mtaylor | lifeless: was afraid of that :) | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!