Try 'bzr branch' instead of 'pull'.
On Tue, May 3, 2011 at 5:17 PM, andi abes wrote:
> I'm not sure who wins in git vs. bzr ease of use... guess it depends on how
> quickly I get over this error:
>
> $ bzr pull lp:swift/1.3
> bzr: ERROR: Cannot lock LockDir(
> http://bazaar.launchpad.net/~swift/
I'm not sure who wins in git vs. bzr ease of use... guess it depends on how
quickly I get over this error:
$ bzr pull lp:swift/1.3
bzr: ERROR: Cannot lock LockDir(
http://bazaar.launchpad.net/~swift/swift/omega-1.3.0-7/.bzr/branch/lock):
Transport oper
ation not possible: http does not support mkd
2011/4/27 Thomas Goirand :
> On 04/27/2011 11:26 PM, Soren Hansen wrote:
>> To get working, yes. To be an expert, no.
>>
>> bzr lp-login
>> (bzr init-repo)
>> bzr branch
>> (bzr add)
>> bzr commit
>> bzr push
>>
>> ..are sufficient to just get started.
> No, I don't agree, it's not enough. See belo
On 04/27/2011 11:26 PM, Soren Hansen wrote:
> To get working, yes. To be an expert, no.
>
> bzr lp-login
> (bzr init-repo)
> bzr branch
> (bzr add)
> bzr commit
> bzr push
>
> ..are sufficient to just get started.
No, I don't agree, it's not enough. See below.
>> and that's most of the time the
2011/4/26 Thomas Goirand :
> On 04/27/2011 02:24 AM, Soren Hansen wrote:
>> 2011/4/26 Thomas Goirand :
>>> On 04/26/2011 10:35 PM, Soren Hansen wrote:
I don't recall seeing anything that makes that a useful nor accurate
summary. Opinions have been voiced, that's all.
>>> Re-read then. Wha
FUJITA Tomonori wrote:
> Why do you think that we (openstack developers) can't live without the
> tools around launchpad? Ten times bigger community (linux kernel) has
> been fine without such tools.
If you are not involved in release management, I'm pretty sure you can
live without release manage
On 04/27/2011 02:24 AM, Soren Hansen wrote:
> 2011/4/26 Thomas Goirand :
>> On 04/26/2011 10:35 PM, Soren Hansen wrote:
>>> I don't recall seeing anything that makes that a useful nor accurate
>>> summary. Opinions have been voiced, that's all.
>> Re-read then. What you believe are opinions might w
On 22 April 2011 18:07, Robert Collins wrote:
> On Fri, Apr 22, 2011 at 4:11 PM, Thomas Goirand wrote:
>>
>> git checkout -b new-soren-branch
>>
>> This is pretty instant. Now do:
>>
>> bzr branch trunk new-soren-branch
>>
>> and wait for all files to copy ...
>
> So, bzr had a design concept at
On Tue, 26 Apr 2011 16:35:56 +0200
Soren Hansen wrote:
>> Why can't we simply use the better tool at this moment?
>
> For the sake of the argument, I'll pretend for second that git is a
> better tool. What happens when the bzr developers fix the shortcomins
> we've identified here, and bzr becom
2011/4/26 Thomas Goirand :
> On 04/26/2011 10:35 PM, Soren Hansen wrote:
>> I don't recall seeing anything that makes that a useful nor accurate
>> summary. Opinions have been voiced, that's all.
> Re-read then. What you believe are opinions might well be seen by their
> authors as useful and accur
On 04/26/2011 10:35 PM, Soren Hansen wrote:
> I don't recall seeing anything that makes that a useful nor accurate
> summary. Opinions have been voiced, that's all.
Re-read then. What you believe are opinions might well be seen by their
authors as useful and accurate points. I mentioned the fact t
On Apr 26, 2011, at 5:37 AM, FUJITA Tomonori wrote:
> Why can't we simply use the better tool at this moment?
Because you will not get agreement on which is "better", as this thread
has amply demonstrated.
I, too, prefer git's design, but I also understand the usefulness of
La
2011/4/26 FUJITA Tomonori :
> Soren Hansen wrote:
>> 2011/4/22 FUJITA Tomonori :
>> Fair enough. That doesn't change that my name is still on the commit,
>> and there might be a bunch of Acked-By's or Tested-By's on there that
>> suddenly are invalid, because those people never tested the patch in
On Fri, 22 Apr 2011 14:52:30 +0200
Soren Hansen wrote:
> 2011/4/22 FUJITA Tomonori :
>>> I find the rebasing/cherry-picking practice even worse in the Linux
>>> kernel context due to the patch tagging used there. If I add a
>>> "Signed-off-by: Soren Hansen" to a patch and someone cherry picks tha
On 04/24/2011 08:27 PM, Soren Hansen wrote:
> There are still *big* projects that still use subversion or even CVS
> (e.g. OpenBSD) and manage to stay productive.
Yes right. So let's go back to use RCS, I'm sure you'll find some
projects still using it! :)
On 04/24/2011 08:27 PM, Soren Hansen wro
2011/4/23 Thomas Goirand :
> On 04/22/2011 08:17 PM, Soren Hansen wrote:
>>> I wasn't discussing rebasing and hiding trials and errors or even
>>> rebasing, but cherry-picking things in a branch that we see fits,
>>> and are ready for a merge.
>> It may not be completely obvious on the surface, but
Hi Soren,
On 04/22/2011 08:17 PM, Soren Hansen wrote:
>> I wasn't discussing rebasing and hiding trials and errors or even
>> rebasing, but cherry-picking things in a branch that we see fits, and
>> are ready for a merge.
>
> It may not be completely obvious on the surface, but those are
> essent
2011/4/22 FUJITA Tomonori :
>> I find the rebasing/cherry-picking practice even worse in the Linux
>> kernel context due to the patch tagging used there. If I add a
>> "Signed-off-by: Soren Hansen" to a patch and someone cherry picks that
>> patch or moves it around as part of a rebase, my patch st
2011/4/22 Thomas Goirand :
> On 04/22/2011 05:41 AM, Soren Hansen wrote:
>> 2011/4/21 Thomas Goirand :
>>> On 04/19/2011 05:55 AM, Soren Hansen wrote:
2011/4/18 Thomas Goirand :
> Can't you just pull each individual patches that you feel ok with? Is
> it simply not technically possibl
On Fri, Apr 22, 2011 at 4:11 PM, Thomas Goirand wrote:
>
> git checkout -b new-soren-branch
>
> This is pretty instant. Now do:
>
> bzr branch trunk new-soren-branch
>
> and wait for all files to copy ...
So, bzr had a design concept at the start that folk should start in
one dir and grow - like
On 04/22/2011 05:41 AM, Soren Hansen wrote:
> 2011/4/21 Thomas Goirand :
>> On 04/19/2011 05:55 AM, Soren Hansen wrote:
>>> 2011/4/18 Thomas Goirand :
Can't you just pull each individual patches that you feel ok with? Is
it simply not technically possible with bzr?
>>> Short answer: no.
On Thu, 21 Apr 2011 23:41:35 +0200
Soren Hansen wrote:
> I find the rebasing/cherry-picking practice even worse in the Linux
> kernel context due to the patch tagging used there. If I add a
> "Signed-off-by: Soren Hansen" to a patch and someone cherry picks that
> patch or moves it around as part
2011/4/21 Vishvananda Ishaya :
> This right here is my main issue with bzr. I can handle the slowness,
Slight change of topic. What exactly is it that you guys find so slow
that you actually feel the need to complain about it? I can't help but
wonder if there's something different in the way we u
On Apr 21, 2011, at 2:41 PM, Soren Hansen wrote:
> I completely agree that bzr should have better mechanics for sharing
> working trees between different branches (the loom plugin does some of
> this, if you're interested). Apart for when I'm working on the Linux
> kernel, I've never really felt
2011/4/21 Thomas Goirand :
> On 04/19/2011 05:55 AM, Soren Hansen wrote:
>> 2011/4/18 Thomas Goirand :
>>> Can't you just pull each individual patches that you feel ok with? Is
>>> it simply not technically possible with bzr?
>> Short answer: no. Longer answer: Of course it's possible to extract
>
On 04/11/2011 09:43 AM, Elliot Murphy wrote:
> Hi!
>
> On Sunday, April 10, 2011, Thomas Goirand wrote:
>> On 04/09/2011 05:21 AM, Jay Pipes wrote:
>>> All,
>>>
>>> In an effort to speed up our code development processes, reduce the
>>> friction amongst existing contributors and reduce barriers t
On Tue, Apr 12, 2011 at 7:28 AM, Robert Collins
wrote:
>> Don't search: sprint is the one!!! As I'm writing this mail, it's 11pm,
>> and I get 20% packet loss... And that's not even peak hours in here
>> (which is between 5 and 8pm local time). I can send traceroutes with mtr
>> if you like, but I
On Tue, Apr 12, 2011 at 3:13 AM, Thomas Goirand wrote:
> I'm not mistaking or dreaming, "bzr commit" as well. Using Git, it's not
> the case. The issue isn't to cache data, the issue is that a commit
> should *never* access any remote data, so that I could work in the train
> without connectivity,
Looks like some awesome enhancements. Thanks for the link, Eric!
-jay
On Sat, Apr 9, 2011 at 11:26 PM, Eric Day wrote:
> Well, GitHub issues may be a bit more suitable for our needs now:
>
> https://github.com/blog/831-issues-2-0-the-next-generation
>
> -Eric
>
> On Fri, Apr 08, 2011 at 05:21:20
On Mon, Apr 11, 2011 at 11:13 AM, Thomas Goirand wrote:
> It unfortunately does. "bzr launchpad-login" for example does, and if
I'll ask the bzr team to think about how to make this more
discoverable, but this will help:
bzr launchpad-login --no-check
All it's really doing is setting the lau
On 04/11/2011 09:43 AM, Elliot Murphy wrote:
> To the open stack community on general, i'd like to say: GitHub
> absolutely rocks, nothing but love for them.
There's one thing: github software itself isn't open source!
Thomas
___
Mailing list: https://
On 04/11/2011 10:52 AM, Robert Collins wrote:
>>> Also, the fact that Git doesn't do network connections
>>> unless its really needed is very welcome.
>
> bzr shouldn't do network connections except when really needed
> *either* : the world is big and networks are slow, so like other DVCS
> the str
On Mon, Apr 11, 2011 at 1:43 PM, Elliot Murphy wrote:
> Hi!
Thanks for CC'ing me on this Elliot.
>> Launchpad is *EXTREMELY* slow from here in Shanghai, and it should be
>> even worth from the center of China. Even doing a simple thing like "bzr
>> launchpad-login" can even fail because of conne
Hi!
On Sunday, April 10, 2011, Thomas Goirand wrote:
> On 04/09/2011 05:21 AM, Jay Pipes wrote:
>> All,
>>
>> In an effort to speed up our code development processes, reduce the
>> friction amongst existing contributors and reduce barriers to entry
>> for new contributors familiar with the popula
On 04/09/2011 05:21 AM, Jay Pipes wrote:
> All,
>
> In an effort to speed up our code development processes, reduce the
> friction amongst existing contributors and reduce barriers to entry
> for new contributors familiar with the popular git DVCS, we (the
> OpenStack@Rackspace team) have been stu
Well, GitHub issues may be a bit more suitable for our needs now:
https://github.com/blog/831-issues-2-0-the-next-generation
-Eric
On Fri, Apr 08, 2011 at 05:21:20PM -0400, Jay Pipes wrote:
> All,
>
> In an effort to speed up our code development processes, reduce the
> friction amongst existin
On 04/08/2011 02:51 PM, Naveed Massjouni wrote:
> On Fri, Apr 8, 2011 at 5:21 PM, Jay Pipes wrote:
>> All,
>>
>> In an effort to speed up our code development processes, reduce the
>> friction amongst existing contributors and reduce barriers to entry
>> for new contributors familiar with the popu
The decision hasn't been made. The decision is to talk about it at the summit
and on the mailing list.
-- Sent from my Tandy 1000sx
Jesse Andrews
anotherje...@gmail.com
On Apr 8, 2011, at 3:08 PM, Rick Clark wrote:
>>
>> Therefore, at this time, we are only proposing moving the code hostin
>
> Therefore, at this time, we are only proposing moving the code hosting
> functionality to GitHub, and not radically changing any other parts of
> the development and release process.
>
> Soren, Monty, and Thierry, who are the developers responsible for
> keeping our release management and dev
On Fri, Apr 8, 2011 at 5:21 PM, Jay Pipes wrote:
> All,
>
> In an effort to speed up our code development processes, reduce the
> friction amongst existing contributors and reduce barriers to entry
> for new contributors familiar with the popular git DVCS, we (the
> OpenStack@Rackspace team) have
Jay,
I think that discussion will be one of the more popular talks at the
summit. Looking forward to the discussion. I know a lot of devs will be
happy to see this.
pvo
On 4/8/11 4:21 PM, "Jay Pipes" wrote:
>All,
>
>In an effort to speed up our code development processes, reduce the
>friction
Hurray!
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
All,
In an effort to speed up our code development processes, reduce the
friction amongst existing contributors and reduce barriers to entry
for new contributors familiar with the popular git DVCS, we (the
OpenStack@Rackspace team) have been studying a transition of our code
hosting from Launchpad
43 matches
Mail list logo
