| justdave | how does one go about creating a new repo that contains multiple branches on a remove server via bzr+ssh ? | 03:51 |
|---|---|---|
| justdave | bzr branch . bzr+ssh://repo/projectname/branchname <- doesn't seem to work if repo/projectname doesn't already exist | 03:51 |
| justdave | s/remove/remote/ | 03:51 |
| justdave | someone told me there's a command line option for bzr branch that makes it create the directory path if it doesn't exist, but I can't find mention of it in bzr help branch | 03:51 |
| lifeless | bzr push is the usual thing to push content | 03:52 |
| mgrandi | do you mean creating a shared repo on a server? | 03:52 |
| lifeless | push --create-prefix ... | 03:52 |
| justdave | mgrandi: yeah, that's what I'm trying to do | 04:00 |
| mgrandi | bzr init-repo <linkhere> | 04:01 |
| justdave | --create-prefix says no such option, init-repo again complains that the parent directory doesn't exist | 04:02 |
| justdave | --create-prefix maybe was added in a newer bzr than I have | 04:03 |
| * justdave looks to see what version he's running | 04:03 | |
| justdave | looks like 2.4.2 on my laptop and 2.3.1 on the server | 04:03 |
| lifeless | justdave: bzr push has a --create-prefix | 04:04 |
| mgrandi | init does too | 04:04 |
| mgrandi | init-repo doesn't look like it does | 04:04 |
| lifeless | init-repo wouldn't need it in the example structure | 04:05 |
| mgrandi | but you can just create the directory on the server | 04:05 |
| lifeless | init-repo bzr+ssh://repo/projectname | 04:05 |
| lifeless | push bzr+ssh://repo/projectname/branchname | 04:05 |
| justdave | woot, push worked, thanks | 04:05 |
| justdave | I have root access on the server end, but was trying to find a way to let people do that self-serve instead of having to have a sysadmin go create directories for them. :) | 04:08 |
| lifeless | naturally :) | 04:10 |
| === echo-are` is now known as echo-area | ||
| goddard | im trying to use bzr to maintain 2 branchs for a web server are there any tutorials on how to go about setting this up | 05:21 |
| poolie | hi | 05:22 |
| poolie | there are some tutes on http://doc.bazaar.canonical.com/ | 05:22 |
| poolie | how do you mean 2 branches for a web server? | 05:22 |
| === r0bby_ is now known as robbyoconnor | ||
| mgz | morning all | 09:04 |
| jelmer | hey mgz | 09:08 |
| mgz | what are you on today jelmer? | 09:51 |
| jelmer | mgz: just coffee, mgz, just coffee | 10:12 |
| mgz | neat:D | 10:14 |
| Pikkachu | tagging logic problem: I have one branch where I pull upstream updates and tag released changesets appropriately, and I have another working base branch which merges these updates from the former branch, but I tag there too as the merges themselves don't inherit the tags | 13:01 |
| Pikkachu | I want advice on this because it may be a lot of tagged merges with single commits which are also tagged with the same tag, it's odd. I'm thinking of just dropping the source tags, how about it? | 13:02 |
| jelmer | Pikkachu: I'm not sure I follow - merges should bring in tags too | 13:04 |
| Pikkachu | jelmer: it does... let me show you | 13:05 |
| Pikkachu | jelmer: http://i.imgur.com/s08YA.png | 13:14 |
| Pikkachu | I forgot of no repeated tags, so the wonder is if the merge has many commits and I wanted to keep track of the source release... | 13:16 |
| Pikkachu | actually the tags aren't the same thing... I like how problems solve themselves in bazaar when you just think logically, I don't care that much whatever embarrassing codebase it may have... thanks all | 13:18 |
| jelmer | Pikkachu: sorry, I'm having trouble understanding what you mean. | 13:19 |
| jelmer | Pikkachu: emberassing codebase? | 13:19 |
| Pikkachu | jelmer: people blame bazaar like it's slow and/or it's a fork of that ugly ancient gnu tool... | 13:20 |
| Pikkachu | jelmer: can you get what I mean in the screenshot? the tags referred to upstream releases in the source branch... | 13:21 |
| jelmer | Pikkachu: The current bzr codebase shares no code whatsoever with tla, and hasn't for the last 7 years. bzr is also reasonably quick these days, at least with 2.5.. | 13:22 |
| Pikkachu | ...but the tags in that branch must refer to the upstream release for which it is targeted | 13:22 |
| jelmer | Pikkachu: anyway, I don't really understand what you're asking about tags.. | 13:22 |
| jelmer | Pikkachu: you're merging from an upstream branch that has tags set? | 13:22 |
| Pikkachu | jelmer: tla wasnt' the name... I'm telling about others say not me, they love to tell people using git because it's cool, and when it comes to eliminating other options, bazaar is usually that one based on <forgot>, slow and worth a joke (then I'm like @@) | 13:24 |
| Pikkachu | jelmer: let's say you have a branch responsible for fetching upstream updates, or it's really an upstream branch and they tag like '2.6.3', '2.7.0' etc for their releases | 13:25 |
| Pikkachu | jelmer: then let's say I forked it at 2.6.3 to add a feature and since then there has been a few commits in upstream, then they release a new version tagging with xyz | 13:26 |
| jelmer | Pikkachu: ok | 13:27 |
| Pikkachu | jelmer: now I want to update my fork and tag it appropriately to point to the respective upstream commits for which they apply (i.e. they'd be immediately subsequent if just applied upstream without forks)... | 13:28 |
| Pikkachu | jelmer: then when merging I can't duplicate xyz, I need to remove it from potentially many sub commits and apply on top of merge | 13:29 |
| Pikkachu | jelmer: but this way I loose information on the original release (I know a given merge matches some release, but within that merge I don't know which commit is the upstream changeset which was released) | 13:30 |
| jelmer | Pikkachu: why do you want to tag the upstream again? | 13:31 |
| Pikkachu | jelmer: solution is using different naming schemes... | 13:31 |
| Pikkachu | jelmer: in the upstream branch? not again... what I want to tag again is my fork | 13:32 |
| jelmer | Pikkachu: Do you want to both have tags for what upstream called a certain release and a tag for the point at which you merged upstream? | 13:32 |
| jelmer | Pikkachu: in that case you indeed want two different tags | 13:32 |
| Pikkachu | jelmer: mostly, except that the latter is 'at the point a merge is ready to match a release' | 13:33 |
| Pikkachu | yeah I'm just thinking of ideas like, say, 'Upstream_1.23' and 'Fork_1.2.3' but these are horrible... | 13:34 |
| Pikkachu | I'm thinking of 'P1.2.3' (Patched 1.2.3) | 13:43 |
| === yofel_ is now known as yofel | ||
| Pikkachu | I have a commit that was released upstream and I want to tag it with the release. It was the last commit, is it ok to uncommit it just for tagging or should I use an empty commit like "Stick on new release xyz"? | 15:43 |
| Pikkachu | hmm nevermind | 15:45 |
| wilx | How often is the Launchpad production code updated? | 17:05 |
| === iBasic is now known as BasicOSX | ||
| mgz | wilx: there's a #launchpad as well for such questions | 17:28 |
| mgz | but basically they have the machinary to update every day at 10:00GMT, generally it's only some weekdays that they actually need to though | 17:29 |
| wilx | Thanks. | 17:39 |
| === lifeless_ is now known as lifeless | ||
| lifeless | mgz: erratta - the time scheduled thing is only for downtime requiring deploys; simple code pushes happen all over the map, and often more than one/day | 17:59 |
| mgz | lifeless: thanks | 18:02 |
| goddard | im trying to use bzr to maintain 2 branchs for a web server are there any tutorials on how to go about setting this up | 18:29 |
| lifeless | goddard: poolie answered you last night; did the answer not help? What sort of additional info would you like ? | 18:30 |
| goddard | lifeless: well he gave me a link to the documentation | 18:31 |
| goddard | but didn't really understand what i was talking about | 18:31 |
| lifeless | yeah | 18:32 |
| lifeless | so I don't understand any more than he did; perhaps you can help me do so? | 18:32 |
| LarstiQ | goddard: what do the two branches contain? | 18:40 |
| goddard | dev site and a live site | 18:41 |
| goddard | here is a git example http://joemaller.com/990/a-web-focused-git-workflow/ | 18:42 |
| goddard | are there bzr type tutorials? | 18:42 |
| goddard | i'd like to be able to read about it | 18:43 |
| LarstiQ | goddard: I will have to read that article | 18:43 |
| LarstiQ | goddard: normally I'd just say: keep your website in a branch and use bzr-upload to deploy | 18:44 |
| goddard | LarstiQ: ok | 18:44 |
| LarstiQ | but maybe you are trying to do something more involved | 18:44 |
| goddard | i dont want to work on this locally | 18:44 |
| * LarstiQ reads | 18:44 | |
| goddard | the enviornment that i would setup would be different from the server | 18:44 |
| goddard | so i guess the dev site would push to the live site | 18:45 |
| goddard | and i would push to the dev site | 18:45 |
| goddard | i think | 18:46 |
| goddard | dont know | 18:46 |
| LarstiQ | goddard: the workflow from the article seems a bit weird to me | 18:49 |
| goddard | if you have a better idea id like to hear it | 18:49 |
| LarstiQ | goddard: I guess it may depend on what you want | 18:50 |
| LarstiQ | goddard: for my purpose I would hack locally, `bzr upload` to the dev site (can be done automatically on commit) till you're happy | 18:51 |
| LarstiQ | then `bzr upload` to the live site with the same revision | 18:51 |
| goddard | alright | 18:53 |
| LarstiQ | but maybe I don't understand the requirements well enough | 18:53 |
| jcsackett | is there a way to change the colorscheme used in "bzr cdiff"? | 20:05 |
| LarstiQ | jcsackett: looking at colordiff.py, not at the moment | 20:23 |
| jcsackett | LarstiQ: ah, thanks. | 20:23 |
| LarstiQ | jcsackett: but it shouldn't be too hard to make it more flexible | 20:23 |
| LarstiQ | jcsackett: basically some configuration that sets self.colors | 20:23 |
| LarstiQ | jcsackett: the DiffWriter class that is | 20:24 |
| poolie | hi all | 22:18 |
| jelmer | 'morning poolie | 22:20 |
| poolie | hi there, how are things? | 22:21 |
| jelmer | alright, how are you? | 22:21 |
| rockstar | Where did bzrlib.tests go? | 23:15 |
| james_w | python-bzrlib.tests package? | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
