Branch Inheritance Problem
21 views
Skip to first unread message
Guillaume M
Nov 17, 2010, 8:31:24 AM11/17/10
to plasticscm
Hello there,
I've been evaluating Plastic SCM, and I would like to ask about an
issue I got with the branch inheritance.
I'll try to describe the issue with an example:
Branch /main/dev inherits from branch /main using dynamic inheritance,
so /main/dev contains the latest revision from /main, unless a
revision already exists for an item in /main/dev.
- I modify and checkin program A and B in /main/dev.
- Then, I Modify and checkin program A and C in /main.
Now, only changes of program C in /main will be present in /main/dev,
but not the ones from A, since A had already a revision in branch /
main/dev. This is what concerns me, since it is highly possible this
result in bug and break the build of /main/dev.
What I would like is PlaticSCM to give an alert when a checkin in /
main would result in revision not being seen by child branches. Or
even beter, PlaticSCM would try to auto-merge in child branches, and
alert me only when conflicts prevent the merge.
I know currently I can perform a merge of /main into /main/dev (and
all other existing child branches) to solve this issue, but this is a
manual operation, and this kind of defeat the purpose of dynamic
inheritance if I always have to manually "merge down" parent into
child...
Maybe I don't understand the concept of dynamic inheritance, and maybe
I don't correctly use it, so I would like to have some feedback on
this issue.
Thanks a lot.
Guillaume.
I've been evaluating Plastic SCM, and I would like to ask about an
issue I got with the branch inheritance.
I'll try to describe the issue with an example:
Branch /main/dev inherits from branch /main using dynamic inheritance,
so /main/dev contains the latest revision from /main, unless a
revision already exists for an item in /main/dev.
- I modify and checkin program A and B in /main/dev.
- Then, I Modify and checkin program A and C in /main.
Now, only changes of program C in /main will be present in /main/dev,
but not the ones from A, since A had already a revision in branch /
main/dev. This is what concerns me, since it is highly possible this
result in bug and break the build of /main/dev.
What I would like is PlaticSCM to give an alert when a checkin in /
main would result in revision not being seen by child branches. Or
even beter, PlaticSCM would try to auto-merge in child branches, and
alert me only when conflicts prevent the merge.
I know currently I can perform a merge of /main into /main/dev (and
all other existing child branches) to solve this issue, but this is a
manual operation, and this kind of defeat the purpose of dynamic
inheritance if I always have to manually "merge down" parent into
child...
Maybe I don't understand the concept of dynamic inheritance, and maybe
I don't correctly use it, so I would like to have some feedback on
this issue.
Thanks a lot.
Guillaume.
David Suarez
Nov 17, 2010, 8:54:47 AM11/17/10
to plast...@googlegroups.com
Hi,
Plastic doesn't automate this scenario as of today, but, since you have to manually indicate when you want to get the branch updated, you can easily create a two lines script that updates and merges for you:
cm update /workspace
cm merge /main --merge
You need to run it when the workspace points to /main/dev, but this will normally be the case from your description. You can use it instead of just "cm update ."
Hope it helps,
David
Plastic doesn't automate this scenario as of today, but, since you have to manually indicate when you want to get the branch updated, you can easily create a two lines script that updates and merges for you:
cm update /workspace
cm merge /main --merge
You need to run it when the workspace points to /main/dev, but this will normally be the case from your description. You can use it instead of just "cm update ."
Hope it helps,
David
Guillaume M
Nov 17, 2010, 10:19:22 AM11/17/10
to plasticscm
The solution you describe will move the responsability of merge
conflicts resolution to the first person who does an update of /main/
dev in its workspace.
I prefer the merge conflicts resolution in child branches to be done
by the person who checkin in /main, at the moment he does the checkin.
The dynamic branch inheritance is one of the main reason why we were
thinking of replacing our current SCM, which currently requires too
much manual merge operation (ex: prod->test->dev->devnext).
But as I understand it, it would still be a manual operation in
Plastic :-(
I'm interested if you have any insight in the future evolution of
branch inheritance in Plastic.
If only I could get a warning by Plastic when doing a commit of a
changeset in a branch, and that branch have some "dynamic" child
branches with revisions on items included in the changeset, this could
at least reduce the manual "merge down", as if i get no warning, I'm
certain that all child branches "sees" the last revisions of their
parent branch.
> David Su�rezwww.codicesoftware.com<http://www.codicesoftware.com>
conflicts resolution to the first person who does an update of /main/
dev in its workspace.
I prefer the merge conflicts resolution in child branches to be done
by the person who checkin in /main, at the moment he does the checkin.
The dynamic branch inheritance is one of the main reason why we were
thinking of replacing our current SCM, which currently requires too
much manual merge operation (ex: prod->test->dev->devnext).
But as I understand it, it would still be a manual operation in
Plastic :-(
I'm interested if you have any insight in the future evolution of
branch inheritance in Plastic.
If only I could get a warning by Plastic when doing a commit of a
changeset in a branch, and that branch have some "dynamic" child
branches with revisions on items included in the changeset, this could
at least reduce the manual "merge down", as if i get no warning, I'm
certain that all child branches "sees" the last revisions of their
parent branch.
>
> Plastic SCM by Codice Software
> <http://www.plasticscm.com><http://www.plasticscm.com>> Plastic SCM by Codice Software
psan...@codicesoftware.com
Nov 17, 2010, 10:49:04 AM11/17/10
to plast...@googlegroups.com
Hi there,
I think we can always create a trigger to actually resolve this specific
scenario, don't you think so David?
pablo
David Suarez
Nov 17, 2010, 10:54:05 AM11/17/10
to plast...@googlegroups.com, Guillaume M
Well, the branch inheritance model in Plastic
is more focused towards a branch per task pattern, where you
divide your work in tasks that are implemented in their specific
branches. That way, developers don't share a /main/dev branch to
work, but instead use child branches for each task, more like
/main/task234, /main/task521, /main/task431. Tasks are well
defined as changes in the code that are short-lived, something
between one hour and 2 days of work.
Those tasks have a well known branch base (starting point), so instead of having dynamic inheritance, they start from a label (a stable point in your code).
You create this stable baselines normally once per week (or the period that better suits your needs, but relatively often). To do so, you merge all the finished branches to /main, but this doesn't affect developers since their branches' bases are set to the previous stable baseline. Once the task branches have been integrated and verified (possibly with a test suite), you apply a new label on /main and you have your new baseline.
This model has several advantages, one of which is that a broken build never affects other developers, and bugs made by one developer are not propagated to others. The other is that you have complete control of what is integrated and what not, so combined with some test suite, you can validate tasks alone and tasks once integrated with others.
This is all described in detail in the quick start guide (http://www.plasticscm.com/infocenter/quick-start.aspx)
Cheers!
David
Those tasks have a well known branch base (starting point), so instead of having dynamic inheritance, they start from a label (a stable point in your code).
You create this stable baselines normally once per week (or the period that better suits your needs, but relatively often). To do so, you merge all the finished branches to /main, but this doesn't affect developers since their branches' bases are set to the previous stable baseline. Once the task branches have been integrated and verified (possibly with a test suite), you apply a new label on /main and you have your new baseline.
This model has several advantages, one of which is that a broken build never affects other developers, and bugs made by one developer are not propagated to others. The other is that you have complete control of what is integrated and what not, so combined with some test suite, you can validate tasks alone and tasks once integrated with others.
This is all described in detail in the quick start guide (http://www.plasticscm.com/infocenter/quick-start.aspx)
Cheers!
David
Guillaume M
Nov 17, 2010, 2:56:16 PM11/17/10
to plasticscm
In my current mindset, the /main branch has many child branches, one
for each development project in our application. Some projects takes 1
week to develop, others may takes 3 months. When project is dev. done,
and it is decided to be part of the next release, it is committed into
the /main. At this point, since the project will be part of the next
release, I think it should be propagated ASAP to the other child
branches, to keep them as close as possible to the /main (otherwise,
longer project would become way to much unsynced from /main).
Moreover, this allows child branches to use new features as soon as
those features are committed to the /main. It give also the
opportunity for child branches to adapt sooner to changes from the /
main, and may catch integration bug sooner.
However, I must confess that our mindshift toward a more agile
development process with branch per task pattern is not yet done.
So the model you describe is not all clear for me.
Where is the "next release" code in your model ? Is it all the changes
that is integrated into /main after the latest baseline label ? Is a
baseline = a version ?
What if a task is dev done, but we are unsure if it will be part of
the next release ? Does it remain *there* without being updated with
latest changes from /main ?
for each development project in our application. Some projects takes 1
week to develop, others may takes 3 months. When project is dev. done,
and it is decided to be part of the next release, it is committed into
the /main. At this point, since the project will be part of the next
release, I think it should be propagated ASAP to the other child
branches, to keep them as close as possible to the /main (otherwise,
longer project would become way to much unsynced from /main).
Moreover, this allows child branches to use new features as soon as
those features are committed to the /main. It give also the
opportunity for child branches to adapt sooner to changes from the /
main, and may catch integration bug sooner.
However, I must confess that our mindshift toward a more agile
development process with branch per task pattern is not yet done.
So the model you describe is not all clear for me.
Where is the "next release" code in your model ? Is it all the changes
that is integrated into /main after the latest baseline label ? Is a
baseline = a version ?
What if a task is dev done, but we are unsure if it will be part of
the next release ? Does it remain *there* without being updated with
latest changes from /main ?
David Suarez
Nov 18, 2010, 7:06:20 AM11/18/10
to plast...@googlegroups.com
Hi,
I attach a diagram on how we'd handle the scenario you propose.
Keep in mind that the releases you generate with pending tasks are kind of checkpoints that you validate, so many of them will be simply internal releases, not necessarily public releases of your software.
In the picture, for instance, a version 2.1.1 is generated on /main, but this is an internal release. Its purpose is to have a stable point that has been validated and can server as the starting point for the new tasks. Then, the ongoing project1 being developed on /main/project1 is rebased to that version of main and a new project1 release is created (in the sample, project version 0.7). The new tasks being developed for project1 now start from this label.
The important fact about these release building and rebase process is that it's a controlled process, there a person responsible for it. This integrator of the releases also ensures that the release has complete tasks that are working and that the release itself is working. This avoids developers getting incomplete code from other developers or bug propagation (you update your workspace and your code no longer works, you don't know if it's a change you made, or the code you downloaded). You avoid "shooting a moving target".
The VCS becomes a safety network where you can checkin as often as you want, instead of a "publishing" tool, where you commit your changes only when they are finished. That has advantages like using diff-debugging and having all the code on your central backed-up server instead of on the developer machines.
The answer to your specific question "where is the next release", in the sample picture, it's first in task branches and when they get integrated, in the project branches. And when the project branches are ready, they are integrated on main.
Hope this helps and doesn't get more confusing :)
Cheers,
David
I attach a diagram on how we'd handle the scenario you propose.
Keep in mind that the releases you generate with pending tasks are kind of checkpoints that you validate, so many of them will be simply internal releases, not necessarily public releases of your software.
In the picture, for instance, a version 2.1.1 is generated on /main, but this is an internal release. Its purpose is to have a stable point that has been validated and can server as the starting point for the new tasks. Then, the ongoing project1 being developed on /main/project1 is rebased to that version of main and a new project1 release is created (in the sample, project version 0.7). The new tasks being developed for project1 now start from this label.
The important fact about these release building and rebase process is that it's a controlled process, there a person responsible for it. This integrator of the releases also ensures that the release has complete tasks that are working and that the release itself is working. This avoids developers getting incomplete code from other developers or bug propagation (you update your workspace and your code no longer works, you don't know if it's a change you made, or the code you downloaded). You avoid "shooting a moving target".
The VCS becomes a safety network where you can checkin as often as you want, instead of a "publishing" tool, where you commit your changes only when they are finished. That has advantages like using diff-debugging and having all the code on your central backed-up server instead of on the developer machines.
The answer to your specific question "where is the next release", in the sample picture, it's first in task branches and when they get integrated, in the project branches. And when the project branches are ready, they are integrated on main.
Hope this helps and doesn't get more confusing :)
Cheers,
David
Guillaume M
Nov 18, 2010, 8:09:35 AM11/18/10
to plasticscm
I can't find the diagram attachment you're talking about.
> I attach a diagram on how we'd handle the scenario you propose.
>
>
David Suarez
Nov 18, 2010, 8:52:45 AM11/18/10
to plast...@googlegroups.com
Guillaume M
Nov 18, 2010, 9:27:42 AM11/18/10
to plasticscm
Thanks David, you diagram makes things clearer. I really like having
projects AND tasks branches.
But, I come back to my original request, about the automatic
propagation to child branches.
In your diagram, when a new baseline is created on /main (ex version
2.1.1), and you want all ongoing project branches to be rebased to
that version, and you want also all ongoing tasks of a project to be
rebased to the new project version. What if you have 10 ongoing
projects, each with dozens of onging tasks ? Does the integrator have
to switch to each branches, and manually perform a merge from /main ?
I hope not.
I'm looking for a way for the integrator to tell Plastic to propagate
all the changes of /main version 2.1.1 to ALL child branches, and be
informed of all the resulting merge conflict. And once conflicts are
all resolved, I can be sure that ALL branches base point is now /main
version 2.1.1.
How is this handled in Plastic ?
projects AND tasks branches.
But, I come back to my original request, about the automatic
propagation to child branches.
In your diagram, when a new baseline is created on /main (ex version
2.1.1), and you want all ongoing project branches to be rebased to
that version, and you want also all ongoing tasks of a project to be
rebased to the new project version. What if you have 10 ongoing
projects, each with dozens of onging tasks ? Does the integrator have
to switch to each branches, and manually perform a merge from /main ?
I hope not.
I'm looking for a way for the integrator to tell Plastic to propagate
all the changes of /main version 2.1.1 to ALL child branches, and be
informed of all the resulting merge conflict. And once conflicts are
all resolved, I can be sure that ALL branches base point is now /main
version 2.1.1.
How is this handled in Plastic ?
David Suarez
Nov 18, 2010, 10:42:03 AM11/18/10
to plast...@googlegroups.com, Guillaume M
Hi,
On 11/18/2010 3:27 PM, Guillaume M wrote:
What if you have 10 ongoing projects, each with dozens of onging tasks ? Does the integrator have to switch to each branches, and manually perform a merge from /main ?
One person is responsible for main, another for projectx, and tasks
are rebased (if needed) by the developers working on them. Task
branches are short-lived. They are used for a few hours, then they
are integrated to create the next internal release, so no need to
rebase them once integrated. You only need to rebase a task branch
that takes longer than your release cycle, which should be the case
very rarely.
If you have many project branches, then you probably have a complex development, so this will help you modeling the responsibilities and keeping it under control.
If you have many project branches, then you probably have a complex development, so this will help you modeling the responsibilities and keeping it under control.
I hope not. I'm looking for a way for the integrator to tell Plastic to propagate all the changes of /main version 2.1.1 to ALL child branches, and be informed of all the resulting merge conflict. And once conflicts are all resolved, I can be sure that ALL branches base point is now /main version 2.1.1. How is this handled in Plastic ?
Let me stress that you want that propagation to be controlled. If
you are the responsible person for projectx, you want to control
what and when changes are coming to your stable branch.
It's a mindset shift from the mainline development concept.
It's a mindset shift from the mainline development concept.
Guillaume M
Nov 18, 2010, 11:10:33 AM11/18/10
to plasticscm
On Nov 18, 10:42 am, David Suarez <dsuar...@codicesoftware.com> wrote:
> Let me stress that you want that propagation to be controlled. If you
> are the responsible person for projectx, you want to control what and
> when changes are coming to your stable branch.
Well, if a project responsible is not happy with the propagation, he
> Let me stress that you want that propagation to be controlled. If you
> are the responsible person for projectx, you want to control what and
> when changes are coming to your stable branch.
can always revert back his branch to before the rebase, but I don't
understand (yet) why he would NOT want to have the latest and greatest
base/stable version from /main.
We'll have to try this different approach.
Thanks David, it was very helpful.
Reply all
Reply to author
Forward
0 new messages