Ubuntu launched Juju http://juju.ubuntu.com earlier this year. Juju
allows anybody to instantly deploy, integrate and scale any server software
on any cloud or server. In seconds you can deploy
Gitlabhttps://jujucharms.com/fullscreen/search/precise/gitlab-2/?text=gitlab#bws-readme.
However we are
On 20.09.2013 20:35, Andreas Krey wrote:
On Fri, 20 Sep 2013 05:57:04 +, Lorenz wrote:
...
Does that actually work again on big repositories?
It used not to, and just omit some.
don't know, never tried it.
But I can't remember anyone posting about a problem either
I definitely had the
What are some of the pros/cons of using a single/shared branch versus the
private developer branch?
We are having an internal debate within the team where the idea of a
single/shared branch was proposed in reaction to two specific issues:
1. In the merge to trunk from individual developer
On 23.09.2013 19:44, C M wrote:
What are some of the pros/cons of using a single/shared branch versus
the private developer branch?
We are having an internal debate within the team where the idea of a
single/shared branch was proposed in reaction to two specific issues:
1. In the merge to
On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer bob.arc...@amsi.com wrote:
It really depends. I think all work for a specific release should be done in
a single branch/folder. Many people follow the stable trunk model. In this
model you generally do all work on trunk and then branch for a
On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer bob.arc...@amsi.com wrote:
It really depends. I think all work for a specific release should be done
in a
single branch/folder. Many people follow the stable trunk model. In this model
you generally do all work on trunk and then branch for a
Unfortunately, we are lacking on processes and there's a definite lack of
product management.
But coming back to my original question: Are there any potential gotchas
with using a single/shared branch? For now, that's the only change the team
(and leadership) is looking to as the solution.
Our
On Mon, Sep 23, 2013 at 2:35 PM, Bob Archer bob.arc...@amsi.com wrote:
On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer bob.arc...@amsi.com wrote:
It really depends. I think all work for a specific release should be done
in a
single branch/folder. Many people follow the stable trunk model. In
If by single/shared branch you mean everyone working out of the same
place...then yes - you'll trip over each other from time to time.
I've worked in both trunk is prestine (all work in branches) and trunk is
dirty (all work in trunk) models; when you have multiple people the trunk is
prestine
What are some of the pros/cons of using a single/shared branch versus the
private developer branch?
We are having an internal debate within the team where the idea of a
single/shared branch was proposed in reaction to two specific issues:
1. In the merge to trunk from individual developer
On 9/23/13 1:15 PM, BRM wrote:
Trunk is dirty won't save you from bad merges, it'll just make more
conflicts in your working copy as you do updates - something that
drove a colleague of mine nuts so I started working in my own branch
for that project. You also have to more frequently be doing
From: C M [mailto:cmanalys...@gmail.com]
Sent: Monday, September 23, 2013 4:05 PM
To: Les Mikesell
Cc: Bob Archer; Subversion
Subject: Re: Shared branch vs single branch
Unfortunately, we are lacking on processes and there's a definite lack of
product management.
But coming back to
If you've got a competent apt builder, why not simply work from the
existing apt or the published RPM packages that set up a template
environment? Or have a word with our commercial Subversion providers, some
of whom have tools like Wandisco's tools for multily hosted, high
availablility
13 matches
Mail list logo
