justdavehow does one go about creating a new repo that contains multiple branches on a remove server via bzr+ssh ?03:51
justdavebzr branch . bzr+ssh://repo/projectname/branchname <- doesn't seem to work if repo/projectname doesn't already exist03:51
justdavesomeone 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 branch03:51
lifelessbzr push is the usual thing to push content03:52
mgrandido you mean creating a shared repo on a server?03:52
lifelesspush --create-prefix ...03:52
justdavemgrandi: yeah, that's what I'm trying to do04:00
mgrandibzr init-repo <linkhere>04:01
justdave--create-prefix says no such option, init-repo again complains that the parent directory doesn't exist04:02
justdave--create-prefix maybe was added in a newer bzr than I have04:03
* justdave looks to see what version he's running04:03
justdavelooks like 2.4.2 on my laptop and 2.3.1 on the server04:03
lifelessjustdave: bzr push has a --create-prefix04:04
mgrandiinit does too04:04
mgrandiinit-repo doesn't look like it does04:04
lifelessinit-repo wouldn't need it in the example structure04:05
mgrandibut you can just create the directory on the server04:05
lifelessinit-repo  bzr+ssh://repo/projectname04:05
lifelesspush bzr+ssh://repo/projectname/branchname04:05
justdavewoot, push worked, thanks04:05
justdaveI 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
lifelessnaturally :)04:10
=== echo-are` is now known as echo-area
goddardim trying to use bzr to maintain 2 branchs for a web server are there any tutorials on how to go about setting this up05:21
pooliethere are some tutes on http://doc.bazaar.canonical.com/05:22
pooliehow do you mean 2 branches for a web server?05:22
=== r0bby_ is now known as robbyoconnor
mgzmorning all09:04
jelmerhey mgz09:08
mgzwhat are you on today jelmer?09:51
jelmermgz: just coffee, mgz, just coffee10:12
Pikkachutagging 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 tags13:01
PikkachuI 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
jelmerPikkachu: I'm not sure I follow - merges should bring in tags too13:04
Pikkachujelmer: it does... let me show you13:05
Pikkachujelmer: http://i.imgur.com/s08YA.png13:14
PikkachuI 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
Pikkachuactually 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 all13:18
jelmerPikkachu: sorry, I'm having trouble understanding what you mean.13:19
jelmerPikkachu: emberassing codebase?13:19
Pikkachujelmer: people blame bazaar like it's slow and/or it's a fork of that ugly ancient gnu tool...13:20
Pikkachujelmer: can you get what I mean in the screenshot? the tags referred to upstream releases in the source branch...13:21
jelmerPikkachu: 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 targeted13:22
jelmerPikkachu: anyway, I don't really understand what you're asking about tags..13:22
jelmerPikkachu: you're merging from an upstream branch that has tags set?13:22
Pikkachujelmer: 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
Pikkachujelmer: 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 releases13:25
Pikkachujelmer: 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 xyz13:26
jelmerPikkachu: ok13:27
Pikkachujelmer: 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
Pikkachujelmer: then when merging I can't duplicate xyz, I need to remove it from potentially many sub commits and apply on top of merge13:29
Pikkachujelmer: 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
jelmerPikkachu: why do you want to tag the upstream again?13:31
Pikkachujelmer: solution is using different naming schemes...13:31
Pikkachujelmer: in the upstream branch? not again... what I want to tag again is my fork13:32
jelmerPikkachu: 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
jelmerPikkachu: in that case you indeed want two different tags13:32
Pikkachujelmer: mostly, except that the latter is 'at the point a merge is ready to match a release'13:33
Pikkachuyeah I'm just thinking of ideas like, say, 'Upstream_1.23' and 'Fork_1.2.3' but these are horrible...13:34
PikkachuI'm thinking of 'P1.2.3' (Patched 1.2.3)13:43
=== yofel_ is now known as yofel
PikkachuI 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
Pikkachuhmm nevermind15:45
wilxHow often is the Launchpad production code updated?17:05
=== iBasic is now known as BasicOSX
mgzwilx: there's a #launchpad as well for such questions17:28
mgzbut basically they have the machinary to update every day at 10:00GMT, generally it's only some weekdays that they actually need to though17:29
=== lifeless_ is now known as lifeless
lifelessmgz: erratta - the time scheduled thing is only for downtime requiring deploys; simple code pushes happen all over the map, and often more than one/day17:59
mgzlifeless: thanks18:02
goddardim trying to use bzr to maintain 2 branchs for a web server are there any tutorials on how to go about setting this up18:29
lifelessgoddard: poolie answered you last night; did the answer not help? What sort of additional info would you like ?18:30
goddardlifeless: well he gave me a link to the documentation18:31
goddardbut didn't really understand what i was talking about18:31
lifelessso I don't understand any more than he did; perhaps you can help me do so?18:32
LarstiQgoddard: what do the two branches contain?18:40
goddarddev site and a live site18:41
goddardhere is a git example http://joemaller.com/990/a-web-focused-git-workflow/18:42
goddardare there bzr type tutorials?18:42
goddardi'd like to be able to read about it18:43
LarstiQgoddard: I will have to read that article18:43
LarstiQgoddard: normally I'd just say: keep your website in a branch and use bzr-upload to deploy18:44
goddardLarstiQ: ok18:44
LarstiQbut maybe you are trying to do something more involved18:44
goddardi dont want to work on this locally18:44
* LarstiQ reads18:44
goddardthe enviornment that i would setup would be different from the server18:44
goddardso i guess the dev site would push to the live site18:45
goddardand i would push to the dev site18:45
goddardi think18:46
goddarddont know18:46
LarstiQgoddard: the workflow from the article seems a bit weird to me18:49
goddardif you have a better idea id like to hear it18:49
LarstiQgoddard: I guess it may depend on what you want18:50
LarstiQgoddard: for my purpose I would hack locally, `bzr upload` to the dev site (can be done automatically on commit) till you're happy18:51
LarstiQthen `bzr upload` to the live site with the same revision18:51
LarstiQbut maybe I don't understand the requirements well enough18:53
jcsackettis there a way to change the colorscheme used in "bzr cdiff"?20:05
LarstiQjcsackett: looking at colordiff.py, not at the moment20:23
jcsackettLarstiQ: ah, thanks.20:23
LarstiQjcsackett: but it shouldn't be too hard to make it more flexible20:23
LarstiQjcsackett: basically some configuration that sets self.colors20:23
LarstiQjcsackett: the DiffWriter class that is20:24
pooliehi all22:18
jelmer'morning poolie22:20
pooliehi there, how are things?22:21
jelmeralright, how are you?22:21
rockstarWhere did bzrlib.tests go?23:15
james_wpython-bzrlib.tests package?23:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!