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
Try 'bzr branch' instead of 'pull'.
On Tue, May 3, 2011 at 5:17 PM, andi abes andi.a...@gmail.com 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(
2011/4/26 Thomas Goirand tho...@goirand.fr:
On 04/27/2011 02:24 AM, Soren Hansen wrote:
2011/4/26 Thomas Goirand tho...@goirand.fr:
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.
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 issues
2011/4/27 Thomas Goirand tho...@goirand.fr:
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.
On Fri, 22 Apr 2011 14:52:30 +0200
Soren Hansen so...@linux2go.dk wrote:
2011/4/22 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp:
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
2011/4/26 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp:
Soren Hansen so...@linux2go.dk wrote:
2011/4/22 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp:
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
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
2011/4/26 Thomas Goirand tho...@goirand.fr:
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
On 22 April 2011 18:07, Robert Collins robert.coll...@canonical.com wrote:
On Fri, Apr 22, 2011 at 4:11 PM, Thomas Goirand tho...@goirand.fr 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,
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
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
essentially
On Fri, Apr 22, 2011 at 4:11 PM, Thomas Goirand tho...@goirand.fr 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
2011/4/22 Thomas Goirand tho...@goirand.fr:
On 04/22/2011 05:41 AM, Soren Hansen wrote:
2011/4/21 Thomas Goirand tho...@goirand.fr:
On 04/19/2011 05:55 AM, Soren Hansen wrote:
2011/4/18 Thomas Goirand tho...@goirand.fr:
Can't you just pull each individual patches that you feel ok with? Is
On 04/11/2011 09:43 AM, Elliot Murphy wrote:
Hi!
On Sunday, April 10, 2011, Thomas Goirand tho...@goirand.fr 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
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 the
On Thu, 21 Apr 2011 23:41:35 +0200
Soren Hansen so...@linux2go.dk 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
On 04/22/2011 05:41 AM, Soren Hansen wrote:
2011/4/21 Thomas Goirand tho...@goirand.fr:
On 04/19/2011 05:55 AM, Soren Hansen wrote:
2011/4/18 Thomas Goirand tho...@goirand.fr:
Can't you just pull each individual patches that you feel ok with? Is
it simply not technically possible with bzr?
On Tue, Apr 12, 2011 at 7:28 AM, Robert Collins
robert.coll...@canonical.com 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
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 strong
Looks like some awesome enhancements. Thanks for the link, Eric!
-jay
On Sat, Apr 9, 2011 at 11:26 PM, Eric Day e...@oddments.org 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
On Tue, Apr 12, 2011 at 3:13 AM, Thomas Goirand tho...@goirand.fr 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
Hi!
On Sunday, April 10, 2011, Thomas Goirand tho...@goirand.fr 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
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 existing
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
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
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 jaypi...@gmail.com wrote:
All,
In an effort to speed up our code development processes, reduce
On Fri, Apr 8, 2011 at 5:21 PM, Jay Pipes jaypi...@gmail.com 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
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
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 hosting
On 04/08/2011 02:51 PM, Naveed Massjouni wrote:
On Fri, Apr 8, 2011 at 5:21 PM, Jay Pipes jaypi...@gmail.com 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
31 matches
Mail list logo
