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

[Maarten Ectors]

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 are missing instant deployment and integration of subversion.
Since Juju is open source, anybody can extend it and use it. If somebody in
the Subversion community would make a "subversion charm", then anybody in
the world would be able to instantly deploy subversion and get it
integrated into a continuous deployment architecture for instance. Find out
more about how easy it is to make a
charm.
You could even win $10,000 if you participate in the Juju Charm
Championshipin the
category Continuous Deployment for instance...

regards,
Maarten Ectors
Responsible for Cloud Strategy at Ubuntu/Canonical

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

[Axel S]

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 problem, but for obvious reason I can't provide
a small repo that exhibits this behaviour, and lacking ideas as to why
this happens, I'm not interestet in taking the time to come up with
a big reproduction. And without that, no bug.


It worked by running 'svn propget svn:externals -R repoURL' and then 
using is as a basis for creating a controlfile and feeding it to svnmucc.


As far as I could see, noe externals were omitted from the svn propget 
output.


Thanks for your help.

Axel

Shared branch vs single branch

[C M]

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 branches, some code was
lost. It remains unclear whether it was user error on part of the person
doing the merge or the tool which caused the problem. In at least one case,
a file was partially merged.

2. The combined functionality (features assigned to two different
developers) was not included in the final application build and delivery.
In this case, the assignments were made months apart and one feature was
delivered without the other.

The expectation is that a shared/single branch will correct these issues. I
am curious to know what advice others can offer and what (if any) potential
issues we may experience with the new paradigm.
Thanks.
Amad.

Re: Shared branch vs single branch

[Branko Čibej]

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 trunk from individual developer branches, some code
> was lost. It remains unclear whether it was user error on part of the
> person doing the merge or the tool which caused the problem. In at
> least one case, a file was partially merged.
>
> 2. The combined functionality (features assigned to two different
> developers) was not included in the final application build and
> delivery. In this case, the assignments were made months apart and one
> feature was delivered without the other.
>
> The expectation is that a shared/single branch will correct these
> issues. I am curious to know what advice others can offer and what (if
> any) potential issues we may experience with the new paradigm.

Changing the way you do branching will not solve your problems, since
the they're by tool but by lack of communication within the team, and
non-existent product management. User error will always happen, but
Subversion will not magically warn you about it. You need other quality
assurance procedures in place for that.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: Shared branch vs single branch

[Les Mikesell]

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 the same model svn itself is developed under. In this model you would 
>> also use what are called "feature" branches. This is generally for a 
>> feature/use case that will take more than a day to complete or will be 
>> worked on by more than one developer.
>
> Once again, it's up to the people not the tool to ensure your release 
> management is done properly.

Well, sort-of.   It is always a good idea to (a) include tests for new
code and (b) have a workflow that ensures that the tests are run and
that someone checks the results.   Expecting one person to never make
a mistake just doesn't always work out.

A general rule can't cover all cases, but in general I think the
longer you let branches diverge with isolated work, the more likely
they are to have conflicting changes that will take extra work to
resolve when you finally do merge.

-- 
  Les Mikesell
lesmikes...@gmail.com

RE: Shared branch vs single branch

[Bob Archer]

> 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 the
> same model svn itself is developed under. In this model you would also use
> what are called "feature" branches. This is generally for a feature/use case 
> that
> will take more than a day to complete or will be worked on by more than one
> developer.
> >
> > Once again, it's up to the people not the tool to ensure your release
> management is done properly.
> 
> Well, sort-of.   It is always a good idea to (a) include tests for new
> code and (b) have a workflow that ensures that the tests are run and
> that someone checks the results.   Expecting one person to never make
> a mistake just doesn't always work out.

Isn't is up to the people to put those processes in place? To create the 
correct workflow? To write the automation? 

I don't think I ever said it should be ONE person's responsibility to manually 
do this work. Where did I say that?

BOb


> 
> A general rule can't cover all cases, but in general I think the longer you 
> let
> branches diverge with isolated work, the more likely they are to have
> conflicting changes that will take extra work to resolve when you finally do
> merge.
> 
> --
>   Les Mikesell
> lesmikes...@gmail.com

Re: Shared branch vs single branch

[C M]

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 developers code on a Unix like platform and have little SVN experience
to boot. The idea of turning over merging to them seems to be a recipe for
disaster. I would prefer to let the CM team handle the merges and figure
out what I did incorrectly to mess up the previous merges.


On Mon, Sep 23, 2013 at 2:42 PM, Les Mikesell  wrote:

> 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 generally do all work on trunk and then branch for a release. This
> is the
> >> same model svn itself is developed under. In this model you would also
> use
> >> what are called "feature" branches. This is generally for a feature/use
> case that
> >> will take more than a day to complete or will be worked on by more than
> one
> >> developer.
> >> >
> >> > Once again, it's up to the people not the tool to ensure your release
> >> management is done properly.
> >>
> >> Well, sort-of.   It is always a good idea to (a) include tests for new
> >> code and (b) have a workflow that ensures that the tests are run and
> >> that someone checks the results.   Expecting one person to never make
> >> a mistake just doesn't always work out.
> >
> > Isn't is up to the people to put those processes in place? To create the
> correct workflow? To write the automation?
> >
> > I don't think I ever said it should be ONE person's responsibility to
> manually do this work. Where did I say that?
>
> You didn't explicitly say it was one person's fault, but what you said
> could easily be interpreted that way by anyone who had to ask the
> question in the first placeYes, people have to set things up,
> but there are tools that can help.
>
> --
>Les Mikesell
>  lesmikes...@gmail.com
>

Re: Shared branch vs single branch

[Les Mikesell]

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 generally do all work on trunk and then branch for a release. This is the
>> same model svn itself is developed under. In this model you would also use
>> what are called "feature" branches. This is generally for a feature/use case 
>> that
>> will take more than a day to complete or will be worked on by more than one
>> developer.
>> >
>> > Once again, it's up to the people not the tool to ensure your release
>> management is done properly.
>>
>> Well, sort-of.   It is always a good idea to (a) include tests for new
>> code and (b) have a workflow that ensures that the tests are run and
>> that someone checks the results.   Expecting one person to never make
>> a mistake just doesn't always work out.
>
> Isn't is up to the people to put those processes in place? To create the 
> correct workflow? To write the automation?
>
> I don't think I ever said it should be ONE person's responsibility to 
> manually do this work. Where did I say that?

You didn't explicitly say it was one person's fault, but what you said
could easily be interpreted that way by anyone who had to ask the
question in the first placeYes, people have to set things up,
but there are tools that can help.

-- 
   Les Mikesell
 lesmikes...@gmail.com

Re: Shared branch vs single branch

[BRM]

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" works a lot better, but as others have noted people doing the merges 
have to ensure they are done right - and that includes testing.

"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 "svn update" on your working copy to minimize 
impacts of what others are doing.

$0.02

Ben





 From: C M 
To: Les Mikesell  
Cc: Bob Archer ; Subversion  
Sent: Monday, September 23, 2013 4:04 PM
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  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 developers code on a Unix like platform and have little SVN experience to 
boot. The idea of turning over merging to them seems to be a recipe for 
disaster. I would prefer to let the CM team handle the merges and figure out 
what I did incorrectly to mess up the previous merges.  




On Mon, Sep 23, 2013 at 2:42 PM, Les Mikesell  wrote:

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 generally do all work on trunk and then branch for a release. This is 
>>> the
>>> same model svn itself is developed under. In this model you would also use
>>> what are called "feature" branches. This is generally for a feature/use 
>>> case that
>>> will take more than a day to complete or will be worked on by more than one
>>> developer.
>>> >
>>> > Once again, it's up to the people not the tool to ensure your release
>>> management is done properly.
>>>
>>> Well, sort-of.   It is always a good idea to (a) include tests for new
>>> code and (b) have a workflow that ensures that the tests are run and
>>> that someone checks the results.   Expecting one person to never make
>>> a mistake just doesn't always work out.
>>
>> Isn't is up to the people to put those processes in place? To create the 
>> correct workflow? To write the automation?
>>
>> I don't think I ever said it should be ONE person's responsibility to 
>> manually do this work. Where did I say that?
>
>You didn't explicitly say it was one person's fault, but what you said
>could easily be interpreted that way by anyone who had to ask the
>question in the first place    Yes, people have to set things up,
>but there are tools that can help.
>
>--
>   Les Mikesell
>     lesmikes...@gmail.com
>

RE: Shared branch vs single branch

[Bob Archer]

> 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 branches, some code was
> lost. It remains unclear whether it was user error on part of the person doing
> the merge or the tool which caused the problem. In at least one case, a file 
> was
> partially merged.

It was the user that did the merge. It will only commit what you tell it to 
commit. This is a people problem, not a branch strategy issue.

> 2. The combined functionality (features assigned to two different developers)
> was not included in the final application build and delivery. In this case, 
> the
> assignments were made months apart and one feature was delivered without
> the other.

Once again, a people problem. 

> The expectation is that a shared/single branch will correct these issues. I am
> curious to know what advice others can offer and what (if any) potential 
> issues
> we may experience with the new paradigm.
> Thanks.
> Amad.

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 the 
same model svn itself is developed under. In this model you would also use what 
are called "feature" branches. This is generally for a feature/use case that 
will take more than a day to complete or will be worked on by more than one 
developer. 

Once again, it's up to the people not the tool to ensure your release 
management is done properly.

BOb

Re: Shared branch vs single branch

[Les Mikesell]

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...) together.

> 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" works a lot better, but as others have noted people doing the
> merges have to ensure they are done right - and that includes testing.

If you use 'trunk is dirty', you will also want 'release' branches so
a broken trunk as you make big changes is not a serious problem.

> "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 "svn update" on your
> working copy to minimize impacts of what others are doing.

Just a matter of whether you want to resolve small conflicts as they
happen with frequent updates/commits  (and maybe take advantages of
other's changes sooner rather than later), or do you want to complete
the changes in isolation so you can prove that your version was the
best and should win if there is a conflict?

-- 
   Les Mikesell
  lesmikes...@gmail.com

Re: Shared branch vs single branch

[Edwin Castro]

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 need to make
decisions about how to resolve those conflicts. Sometimes the knowledge
required is tool usage (handling tree conflicts for example) but at
other times you need to understand what two diverging lines of code are
trying to do in order to make a correct choice.

Re: Shared branch vs single branch

[Edwin Castro]

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 "svn
> update" on your working copy to minimize impacts of what others are doing.

In my experience, working in a dirty trunk typically results in less
checkins by developers. I don't consider this a good thing as their
changes tend to remain uncommitted for very large periods of time (in
the order of a week or so).

Re: Shared branch vs single branch

[Edwin Castro]

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 more frequently be doing "svn update" on your
>> > working copy to minimize impacts of what others are doing.
> Just a matter of whether you want to resolve small conflicts as they
> happen with frequent updates/commits  (and maybe take advantages of
> other's changes sooner rather than later), or do you want to complete
> the changes in isolation so you can prove that your version was the
> best and should win if there is a conflict?

The isolation provided by branches can result in code that diverges
greatly because the child branch is not kept in sync with its parent.
Large time periods of isolation can cause some very hairy merges.

RE: Shared branch vs single branch

[Andrew Reedick]

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

Firstly, one branch only works if you only ever have one and only one 
development steam going at a time.  This "never" happens because at a minimum, 
you need a branch to support production fixes, a branch for QA fixes for the 
"final" release candidate, and a branch for the next release, e.g.:
* /branches/1.0.1 - prod bug fixes for 1.0.0 in prod
* /branchs/1.1.0 - 1.1.0 is in its final round of QA testing, so only 1.1.0 bug 
fix work is accepted
* /branches/trunk (aka 2.0 work)
In other words, don't ignore, gloss over, or otherwise lie to yourselves over 
the need to support multiple branches and merging.

Secondly, everyone will still require training.  Multiple branches (see Firstly 
above) will require training for everyone.  Even if you have the CM guy do the 
merges, you still need to teach the developers how to avoid creating Evil Twins 
(i.e. a particular Tree Conflict.)  An Evil Twin is created when you 'svn add 
foo.java' on both the trunk and on the branch, instead of merging 'foo.java' 
from trunk to the branch.

Thirdly, you need process and project management.  If you can't track your 
work, even "single" branching is going to fail hard, such as when you have to 
back a feature out of trunk due to time constraints.  If you can't 
identify/track the work back to individual check-ins, then you will have great 
difficulty in reverse merging a feature out of trunk and merging it to its own 
branch.  If you can't assign work and/or manage requirements, then, 
technically, you cannot, in good faith, decide whether single or multiple 
branches are right for you.

Fourthly, Semper Gumby; "Always Flexible."  Branching gives you flexibility.  
Going with single branching limits your ability to change, adapt to, or manage 
releases.  If you have lousy requirements management, then single branching 
means you're more likely to wind up in death marches, late nights, and relying 
on full regression testing (which takes time that you won't have) to verify 
that you all haven't broken something stupid on trunk.  If I had 
lousy/incomplete/late requirements then I would want to use feature branches to 
help mitigate the pain.

Fifthly, keep your resume up to date.  A good marriage counselor helps as well. 
 Keep in contact with your company recruiter in case you experience higher than 
average developer burn out.  Over-dramatic, but no process == inefficient work 
== making up the time with people's personal time, i.e. late hours, weekend 
work, etc..


To actually answer your question, the pitfalls of single branching are:
a) people working on the same files will create conflicts during 'svn update'.  
However, svn locking can help reduce the pain.  Dividing up the work so that 
folks are working on different parts of the software helps as well.  
Communication is key when multiple developers touch the same set of files.

b) having to remove code.  If a feature is unstable or cannot be completed in 
time, then you will need to reverse merge it out.  Which can be more difficult 
with single branching over feature branching.  Difficultly is increased the 
longer/bigger the release is, due to the increased chance of interdependencies 
with the removed feature.

However, if you're doing Agile development (short release cycles/sprints, a 
small set of well defined requirements for each sprint, etc.) then the dirty 
trunk approach should work mostly easily.  However, the longer your release 
cycle, the greater your chances of having to rip out a feature and the greater 
the difficulty it will be in doing so (due to dependencies, larger set of QA 
test to run through, etc..)
 

> Our developers code on a Unix like platform and have little SVN experience to 
> boot. The idea of turning over merging to them seems to be a recipe for 
> disaster. I would prefer to let the CM team handle the merges and figure out 
> what I did incorrectly to mess up the previous merges.  

Go with the trained CM guy.  Tree conflicts in Subversion aren't exactly well 
documented and require some experience to do correctly.  However, your CM guy 
can't merge based on business logic, e.g. if something *shouldn't* be merged 
(such as a temporary hack) then you Someone(tm) needs to work with the Merge 
Meister, i.e. have a merge party.

Good luck.  It doesn't have to be perfect, but the more up front planning you 
do, the less of your life you lose to stress.  Also, defining a process is the 
first step towards process improvement and a saner career.  =)

/

Re: Shared branch vs single branch

[Ben Reser]

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.  Which strategy you
want to use is entirely situational.

If you're using a single shared trunk then you're going to run into situations
where you'll want to still use a branch because the work being done is
disruptive.  The only alternative to that is to start adding flags in your
build system to hide this.

If you use branches often, then you'll still have changes where they are small
enough there's no need for the branch.

> Our developers code on a Unix like platform and have little SVN experience to
> boot. The idea of turning over merging to them seems to be a recipe for
> disaster. I would prefer to let the CM team handle the merges and figure out
> what I did incorrectly to mess up the previous merges. 

In truth every commit is a merge (the HTTP method SVN uses for commit is
MERGE).  Who better to be committing/merging than your developers?

Consider the following situation.  Developer A and B are both working on a
project we'll call widgets.  The code has the following layout.

widgets
  widget/foo.c
  widget/bar.c
  widget/baz.c
  main.c

Developer A starts modifying a function we'll call stamp(), let's pretend that
stamp controls the formatting of a date and serial number coding on the widgets
we're producing and lives in main.c.  foo and bar widgets have this coding but
the baz widget is new and hasn't had it added yet.  Developer A has been given
the task of adding a time code to the stamp.  Developer A has an entire working
copy at revision 20.

Developer B is working on the baz widget and is now getting to the point of
adding the stamp and adds a call to stamp() to baz.c.  He commits revision 21
doing so.

Developer A continues working against revision 20 has finished adding time to
stamp() and in the process adding a new argument to input the time to stamp.
He updated the calls in foo.c and bar.c but since he only has r20 he doesn't
see that widget/baz.c has added such a call.  He commits his code in r22.

Now the baz widget has been broken.  Subversion didn't complain because the
changes were in different files and don't appear to conflict.

Now consider if both developers had been working on branches.  If they merge
their branches back to trunk in the same order then you'll have the same 
problem.

All branches do is delay the conflict and potentially limit the number of
people that are impacted by the conflict.  In my opinion the further you get
from the creation of the conflict both in time and individuals the harder it is
going to be to fix it.  But that also doesn't mean you should never use 
branches.

I really don't understand how CM doing merges helps avoid problems.  The
developers are in the best position to understand the impacts of their merges
and deal with any conflicts (raised by Subversion or semantic and not shown as
a conflict by Subversion).

If you're uncomfortable with your developers knowledge of Subversion, you
should invest in them and spend the time improving that knowledge.  It'll pay
off more than any change in branch strategies ever can, since as I demonstrated
above, both strategies can have the identical problem.

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

[Nico Kadel-Garcia]

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?


On Mon, Sep 23, 2013 at 6:18 AM, Maarten Ectors <
maarten.ect...@canonical.com> wrote:

> 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 are missing instant deployment and integration of subversion.
> Since Juju is open source, anybody can extend it and use it. If somebody in
> the Subversion community would make a "subversion charm", then anybody in
> the world would be able to instantly deploy subversion and get it
> integrated into a continuous deployment architecture for instance. Find out
> more about how easy it is to make a 
> charm.
> You could even win $10,000 if you participate in the Juju Charm
> Championship  in the
> category Continuous Deployment for instance...
>
> regards,
> Maarten Ectors
> Responsible for Cloud Strategy at Ubuntu/Canonical
>