Re: Gitlab is looking for alternatives on Juju, the latest Open Source product from Ubuntu

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 Subversion

Re: Shared branch vs single branch

On 9/23/13 1:04 PM, C M wrote: > 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". In my opinion there isn't a single answer to this question.

RE: Shared branch vs single branch

> 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 ba

Re: Shared branch vs single branch

On 9/23/13 1:45 PM, Les Mikesell 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 m

Re: Shared branch vs single branch

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 d

Re: Shared branch vs single branch

On 9/23/13 1:04 PM, C M wrote: > The idea of turning over merging to them seems to be a recipe for > disaster. IMHO, merges should be performed by the individual who is most knowledgeable of the code being merged. When conflicts occur, and they WILL occur, the individual performing the merge will

Re: Shared branch vs single branch

On Mon, Sep 23, 2013 at 3:15 PM, BRM wrote: > 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. Conflicts are going to happen. The question is more about the timing - and how your team works (or fights...) t

RE: Shared branch vs single branch

> 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 develope

Re: Shared branch vs single branch

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 pr

Re: Shared branch vs single branch

On Mon, Sep 23, 2013 at 2:35 PM, Bob Archer wrote: >> On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer 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 general

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 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

RE: Shared branch vs single branch

> On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer 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 release. This i

Re: Shared branch vs single branch

On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer 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 release. This >> is

Re: Shared branch vs single branch

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 merg

Shared branch vs single branch

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 branche

Re: Change all existing static externals in tags from operative to peg?

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 pro

Gitlab is looking for alternatives on Juju, the latest Open Source product from Ubuntu

Ubuntu launched Juju 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 Gitlab. However we a