The Git Branching Model: Will it work with SVN?

[Alex Harui <ah...@adobe.com>]

So, while the poll is leaning towards an unstable branch, there seems to be
a lot of interest in the Git Branching Model described here [1].

This seems like a more complex branching scheme than I was envisioning, but
it seems to be working for folks.  The question is: does anyone have any
concerns about how well it will work with SVN?  I'm thinking we won't switch
to Git until after Adobe donates 3.x at the earliest.  That's the last known
donation that will have SVN history.

In my understanding of the model, our trunk would be the "master" described
in the model and the "unstable" branch would be the "develop" branch in the
model.  I say that because the very top-most arrow indicates that "develop"
is a branch of "master".

I am thinking of running a new poll that includes this model, but I want to
make sure that there isn't going to be an obvious show-stopper with SVN if
it wins.

I also pondered the notion of a variant where SVN trunk is the "master" and
we use a Git branch as the "develop" branch.  I don't know much about Git so
I don't know if that would cause more problems or not, but it would allow us
to keep SVN around for the 3.x import.

[1] http://nvie.com/posts/a-successful-git-branching-model/

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: The Git Branching Model: Will it work with SVN?

[Omar Gonzalez <om...@gmail.com>]

> >> In the Git Branching Model, you would do the merge, resolve conflicts
> and
> >> block manually resolved conflicts.
> > Which doesn't answer my question of how you would keep develop/unstable
> in
> > sync with the trunk. (See above).
> In the Git Branching Model, the trunk only receives merges from release
> branches.  The release branch gets synced with trunk and develop.  All
> changes to trunk that should be in develop should be in at that time.  It
> must be working satisfactorily otherwise it wouldn't have fans.
>

This is a little bit wrong.
In the Git Branching Model, trunk/master receives merges from release
branches and from hotfix branches, whenever there is something to be fixed
on a version that has already been deployed. Those hotfix branches are made
off a version tag. It works extremely well in Git, more on that in next
answer below.



>
> >
> >> I think the trunk history may not be any different if we use the Git
> >> Branching Model entirely in SVN because the only commit to trunk is
> from a
> >> release branch merge operation.
> > Can you think of any way to keep the revision history?
>

This model works very well in Git because of rebasing. You can read more
about Git rebase here: http://learn.github.com/p/rebasing.html
Rebasing is one of the reason this model works so well. It basically plays
back commits, in chronological order, so you can resolve conflicts as they
appear in smaller chunks as opposed to big huge merges like people usually
fear with SVN.


To be quite honest, I'm not entirely sure how well this scheme would work
with SVN, I think that it can work cleanly, but there may be some merging
pain that surfaces every now and then.

I think moving to Git sooner is better than waiting. I do understand the
SVN history concern, but that can still be imported into SVN and then
sync'd to Git once its been imported, I don't see any real reason for the
pending donations to be an obstacle on moving to Git for a better workflow.
Especially if we're moving to the Git branching model, then I don't see any
issues honestly.

-omar

Re: The Git Branching Model: Will it work with SVN?

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> If we switched to Git then it'd have to be with the Git Branching Model.
Exactly. It could not be a single development/unstable branch. I'd be for using git in that way.

Justin

Re: The Git Branching Model: Will it work with SVN?

[Omar Gonzalez <om...@gmail.com>]

On Thu, Aug 9, 2012 at 11:16 PM, Justin Mclean <ju...@classsoftware.com>wrote:

> HI,
>
> > If we could just switch to Git we wouldn't have any of these stupid
> > problems with merging to begin with.
>
> Or is using SVN by working in trunk or have short lived branches as
> needed. It's hot hard or complex when used that way. Why are we even
> considering using a tool in the way that is not recommended?
>

I just dont see a bunch of people working in the trunk being as efficient.
Having things in different branches with an organized workflow like the Git
Branching Model has very defined workflows for all of the aspect of a
project's lifecycle. The SVN document has 3 different approaches, The
Always Branch is closest to the Git Branching Model, if we had to stick
with SVN that's the option I would choose and I'd try to mimic the GBM
simply because of the good experiences I've had with it on teams I've
worked with.

Having lots of people moving things around in the trunk at any given time
is going to cause chaos. It will also make it more difficult to keep the
trunk in a ready to ship state.


>
> > Yes, I'm trying to push the conversation in the direction of switching
> the
> > entire SCM solution. It would be best for the project to step out of the
> > dark ages of SCM and into the new age.... ;-)
>
> I'd also be fine with using Git.
>
> But I think the issue it how will we using it not exactly which version
> control we use ie a single development/unstable branch or not, check into
> trunk or not etc etc
>

If we switched to Git then it'd have to be with the Git Branching Model. It
takes advantage of two of Gits most killer features, branching and
merging/rebasing. I really do think this project would run a lot smoother
if we moved to this pairing. A lot of people would be happier. You can
branch branch branch all day locally and its extremely fast. Its easy to
publish branches and share code between experimental branches with other
devs. Merges have way less problems because of the hash nature as opposed
to chronological timeline based revisions. That's why you can just move
commits from branch to branch with ease. There's so many benefits to it.

-omar

Re: The Git Branching Model: Will it work with SVN?

[Justin Mclean <ju...@classsoftware.com>]

HI,

> If we could just switch to Git we wouldn't have any of these stupid
> problems with merging to begin with.

Or is using SVN by working in trunk or have short lived branches as needed. It's hot hard or complex when used that way. Why are we even considering using a tool in the way that is not recommended?

> Yes, I'm trying to push the conversation in the direction of switching the
> entire SCM solution. It would be best for the project to step out of the
> dark ages of SCM and into the new age.... ;-)

I'd also be fine with using Git. 

But I think the issue it how will we using it not exactly which version control we use ie a single development/unstable branch or not, check into trunk or not etc etc

Thanks,
Justin

Re: The Git Branching Model: Will it work with SVN?

[Omar Gonzalez <om...@gmail.com>]

On Thu, Aug 9, 2012 at 10:45 PM, Justin Mclean <ju...@classsoftware.com>wrote:

> Hi,
>
> > You can request the log to include merge-info and it
> > will.  SmartSVN shows it as child nodes of the merged log entry.
> So we need to use a commercial plug in in order to see the full log
> history? Using the command line for history is not really practical on code
> base this large.
>

I don't think Alex is saying you have to use a commercial plug in, just
pointing out how SmartSVN's GUI shows it. SmartSVN is not a plug in either,
its an SVN client.


>
> > No, I will continue to propose the tiered approach as I still think it is
> > simpler, but I will give folks a third option of the Git Branching Model.
> OK so it seems we still have no consensus until we do (and you can
> convince me otherwise) do I'll continue to work in trunk.
>




>
> > I am not an expert, but I do not believe your scenario can cause a merge
> in
> > the Git Branching Model or the tiered model because the changes you
> apply to
> > the destination will not have already changed in the destination.
> You will end up with a trunk that could be broken and an another branch
> that is out of sync because it is missing changes made in trunk.
>

If we could just switch to Git we wouldn't have any of these stupid
problems with merging to begin with.


>
> > And again, I don't see how that would cause a merge conflict.
> Because you have cherrypicked changes/only committed some changesets and
> not merged the entire branch. As you merge one persons changelists one by
> one you can get a conflict due to unapplied changesets from other people.
>

Again, problems that don't happen in Git because of the fundamental ways in
which in handles merging and revisions.

Yes, I'm trying to push the conversation in the direction of switching the
entire SCM solution. It would be best for the project to step out of the
dark ages of SCM and into the new age.... ;-)

-omar

Re: The Git Branching Model: Will it work with SVN?

[Bertrand Delacretaz <bd...@apache.org>]

On Fri, Aug 10, 2012 at 8:42 AM, Alex Harui <ah...@adobe.com> wrote:
> ...If I understood Bertrand, the results of the poll will be binding, so you
> have to work within whichever plan wins....

Sorry, I wasn't clear: a [POLL] is just a poll, if a binding decision
is needed that's at [VOTE].

But it's much better to reach consensus before starting a vote - if
the vote is a fight for who gets the more +1s that usually hides a
deeper problem.

-Bertrand

Re: The Git Branching Model: Will it work with SVN?

[Carlos Rovira <ca...@codeoscopic.com>]

> I'm thinking we won't switch
to Git until after Adobe donates 3.x at the earliest.

Alex, why Flex 3.x should be a showstopper for go to Git? I think it could
be donated to Apache SVN and then incorporate to Git when it comes the
time. I don't see the relation here, but a problem for Flex 4.x - 5.x
evolution that would be more easy by going git as soon as possible...



2012/8/10 Omar Gonzalez <om...@gmail.com>

> All merge of of trunk from unstable can cause conflicts if for example
> > someone deleted or renamed a file in one changeset and someone else
> > modified the same file in another changeset.
>
>
> This is also another issue that can be solved with using Git because of
> rebasing. Rebasing branches undoes all of the commits you've done up to the
> point at which you started the branch. It stores them away and then pulls
> down all of the new commits that were done on the parent that you created
> the branch from. Once it has all the commits they're reapplied to the
> branch in chronological order so you can maintain a perfect commit history
> and be able to resolve conflicts as they happen in small chunks as opposed
> to trying to resolve huge changesets like you do in SVN.
>
> Git, git, git!
>
> -omar
>



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid

Re: The Git Branching Model: Will it work with SVN?

[Omar Gonzalez <om...@gmail.com>]

All merge of of trunk from unstable can cause conflicts if for example
> someone deleted or renamed a file in one changeset and someone else
> modified the same file in another changeset.


This is also another issue that can be solved with using Git because of
rebasing. Rebasing branches undoes all of the commits you've done up to the
point at which you started the branch. It stores them away and then pulls
down all of the new commits that were done on the parent that you created
the branch from. Once it has all the commits they're reapplied to the
branch in chronological order so you can maintain a perfect commit history
and be able to resolve conflicts as they happen in small chunks as opposed
to trying to resolve huge changesets like you do in SVN.

Git, git, git!

-omar

Re: The Git Branching Model: Will it work with SVN?

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> No, it is an option on the command=line as well as described further down in
> the article I posted a couple of replies back.
And as I said with this large a code base looking through history via the command line is hardly ideal.

> If I understood Bertrand, the results of the poll will be binding, so you
> have to work within whichever plan wins.
Despite you only putting 2 options of all those that have been discussed? And only one of the 3 options I actually put forward.

> I hope the develop branch will hardly every match trunk completely because
> it will be containing changes not yet ready for primetime.
That fine and no issues with that. But I'm taking about changes made to trunk that are not in the unstable branch.

> I am not an expert, but my undertanding is that cherrypicking doesn't cause
> merge conflicts although it could result in something being broken if you
> miss an important revision. But that should be found in testing of the
> release branch before it gets merged to trunk.
Hopefully yes. However in fixing anything that is broken in this way you'll need to check into trunk. How do you then sync the unstable branch with that change that has just been made in trunk?

All merge of of trunk from unstable can cause conflicts if for example someone deleted or renamed a file in one changeset and someone else modified the same file in another changeset. Other issues can also cause conflicts see:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.mergeconflicts

We would also need to block any SVN client that use 1.5 or below:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients

Justin

Re: The Git Branching Model: Will it work with SVN?

[Alex Harui <ah...@adobe.com>]

On 8/9/12 10:45 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>> You can request the log to include merge-info and it
>> will.  SmartSVN shows it as child nodes of the merged log entry.
> So we need to use a commercial plug in in order to see the full log history?
> Using the command line for history is not really practical on code base this
> large.
No, it is an option on the command=line as well as described further down in
the article I posted a couple of replies back.
> 
>> No, I will continue to propose the tiered approach as I still think it is
>> simpler, but I will give folks a third option of the Git Branching Model.
> OK so it seems we still have no consensus until we do (and you can convince me
> otherwise) do I'll continue to work in trunk.
If I understood Bertrand, the results of the poll will be binding, so you
have to work within whichever plan wins.
> 
>> I am not an expert, but I do not believe your scenario can cause a merge in
>> the Git Branching Model or the tiered model because the changes you apply to
>> the destination will not have already changed in the destination.
> You will end up with a trunk that could be broken and an another branch that
> is out of sync because it is missing changes made in trunk.
I hope the develop branch will hardly every match trunk completely because
it will be containing changes not yet ready for primetime because we'll have
lots of active committers.  My understanding of the Git Branching model is
that trunk is essentially a mirror of a non-broken release branch so I don't
see trunk being broken under that plan.
> 
>> And again, I don't see how that would cause a merge conflict.
> Because you have cherrypicked changes/only committed some changesets and not
> merged the entire branch. As you merge one persons changelists one by one you
> can get a conflict due to unapplied changesets from other people.
I am not an expert, but my undertanding is that cherrypicking doesn't cause
merge conflicts although it could result in something being broken if you
miss an important revision. But that should be found in testing of the
release branch before it gets merged to trunk.
> 
> Thanks,
> Justin
> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: The Git Branching Model: Will it work with SVN?

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> You can request the log to include merge-info and it
> will.  SmartSVN shows it as child nodes of the merged log entry.
So we need to use a commercial plug in in order to see the full log history? Using the command line for history is not really practical on code base this large.

> No, I will continue to propose the tiered approach as I still think it is
> simpler, but I will give folks a third option of the Git Branching Model.
OK so it seems we still have no consensus until we do (and you can convince me otherwise) do I'll continue to work in trunk.

> I am not an expert, but I do not believe your scenario can cause a merge in
> the Git Branching Model or the tiered model because the changes you apply to
> the destination will not have already changed in the destination.
You will end up with a trunk that could be broken and an another branch that is out of sync because it is missing changes made in trunk.

> And again, I don't see how that would cause a merge conflict.
Because you have cherrypicked changes/only committed some changesets and not merged the entire branch. As you merge one persons changelists one by one you can get a conflict due to unapplied changesets from other people.

Thanks,
Justin

Re: The Git Branching Model: Will it work with SVN?

[Alex Harui <ah...@adobe.com>]

On 8/9/12 9:15 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>> Well, there might be a better way, but by your reasoning we would never
>> branch.
> No I am against have a single unstable branch. I see far less issues if we did
> use multiple branches (ie one branch per change) OR most small changes in
> trunk and branch when needed as suggested by the SVN best practice document.
I am specifically asking about the Git Branching Model in this thread, which
I don't believe conforms to either of patterns you like.  However, I did
find the better way.  You can request the log to include merge-info and it
will.  SmartSVN shows it as child nodes of the merged log entry.
> 
>>> We not talking about the git branching model we are talking about using a
>>> single unstable branch or so I thought?
>> Not in this thread, see subject.
> OK so just to confirm you now think that a singe unstable branch is not the
> way to go?
No, I will continue to propose the tiered approach as I still think it is
simpler, but I will give folks a third option of the Git Branching Model.
 
> 
>> Maybe you can provide an example?  I don't see how one way pushes from
>> unstable/develop can cause a conflict in trunk.
> Because of existing changes that have not been pushed into trunk. Person A
> checks in files A,B and C (in one changeset), Person B modifies and checks in
> file B, Person A then modifies and checks in file B again all in a non trunk
> branch. Merging persons A changeset with trunk could then likely to cause an
> issue and the trunk may not be in a usage state. To fix that you then have to
> make changes directly to trunk and then you would need to sync those changes
> with the branch. The simple way around this issue is to always merge entire
> branches.
I am not an expert, but I do not believe your scenario can cause a merge in
the Git Branching Model or the tiered model because the changes you apply to
the destination will not have already changed in the destination.

> 
> I also read carefully the "More on Merge Conflicts" section in the link you
> provide. Yes you can cherrypick and block changesets (and shown in the link
> you provided) but it's seem overly complex to need to do that all the time
> rather than is just exceptional circumstances.
I disagree that this will happen "all the time".  But we'll find out because
I expect either the tiered model will win again or the Git Branching Model
will win and we will be doing merges.
> 
>> In the Git Branching Model, when we decide we want to prepare a release
>> (which would not be daily) we would cut a release branch from develop and
>> either take a bunch of known good commits or take from the head, remove and
>> block.
> In which I think you run into the same issues as above re using a single
> branch and selecting changesets.
And again, I don't see how that would cause a merge conflict.
> 
>> In the Git Branching Model, you would do the merge, resolve conflicts and
>> block manually resolved conflicts.
> Which doesn't answer my question of how you would keep develop/unstable in
> sync with the trunk. (See above).
In the Git Branching Model, the trunk only receives merges from release
branches.  The release branch gets synced with trunk and develop.  All
changes to trunk that should be in develop should be in at that time.  It
must be working satisfactorily otherwise it wouldn't have fans.

> 
>> I think the trunk history may not be any different if we use the Git
>> Branching Model entirely in SVN because the only commit to trunk is from a
>> release branch merge operation.
> Can you think of any way to keep the revision history? It's sometime very
> useful to know what small changes were made when, rather than knowing a whole
> lot of files and lines changed in this release.
It appears that by asking for merge-info in the logs you can see all the
changes that went into a merge.
> 
> Thanks,
> Justin

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: The Git Branching Model: Will it work with SVN?

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Well, there might be a better way, but by your reasoning we would never
> branch.
No I am against have a single unstable branch. I see far less issues if we did use multiple branches (ie one branch per change) OR most small changes in trunk and branch when needed as suggested by the SVN best practice document.

>> We not talking about the git branching model we are talking about using a
>> single unstable branch or so I thought?
> Not in this thread, see subject.
OK so just to confirm you now think that a singe unstable branch is not the way to go? 

> Maybe you can provide an example?  I don't see how one way pushes from
> unstable/develop can cause a conflict in trunk.
Because of existing changes that have not been pushed into trunk. Person A checks in files A,B and C (in one changeset), Person B modifies and checks in file B, Person A then modifies and checks in file B again all in a non trunk branch. Merging persons A changeset with trunk could then likely to cause an issue and the trunk may not be in a usage state. To fix that you then have to make changes directly to trunk and then you would need to sync those changes with the branch. The simple way around this issue is to always merge entire branches.

I also read carefully the "More on Merge Conflicts" section in the link you provide. Yes you can cherrypick and block changesets (and shown in the link you provided) but it's seem overly complex to need to do that all the time rather than is just exceptional circumstances.

> In the Git Branching Model, when we decide we want to prepare a release
> (which would not be daily) we would cut a release branch from develop and
> either take a bunch of known good commits or take from the head, remove and
> block.
In which I think you run into the same issues as above re using a single branch and selecting changesets.

> In the Git Branching Model, you would do the merge, resolve conflicts and
> block manually resolved conflicts.
Which doesn't answer my question of how you would keep develop/unstable in sync with the trunk. (See above).

> I think the trunk history may not be any different if we use the Git
> Branching Model entirely in SVN because the only commit to trunk is from a
> release branch merge operation.
Can you think of any way to keep the revision history? It's sometime very useful to know what small changes were made when, rather than knowing a whole lot of files and lines changed in this release.

Thanks,
Justin

Re: The Git Branching Model: Will it work with SVN?

[Alex Harui <ah...@adobe.com>]

On 8/9/12 8:26 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>> For us, the trunk log said things like "Merge revs 100-150 from Unstable"
>> and you would go to the Unstable working copy and view the logs there.
> I think that's a significant technical negative to not use this approach.
Well, there might be a better way, but by your reasoning we would never
branch.

>> 
>>> 2. How do we deal with conflicts in trunk when merging changesets from the
>>> unstable branch.
>> This should in theory be extremely rare in the Git branching model because
>> there shouldn't be any independent changes to trunk/master.
> We not talking about the git branching model we are talking about using a
> single unstable branch or so I thought?
Not in this thread, see subject.
> IMO conflicts will be reasonable
> common as you need to check in multiple changesets from a single person from
> unstable to trunk when other people have made changes in unstable as well. If
> we were checking all of unstable into trunk there would be less issue but you
> can't do that as some people's changes may not be ready to check into trunk.
Maybe you can provide an example?  I don't see how one way pushes from
unstable/develop can cause a conflict in trunk.
> 
>> After resolving a conflict by hand-merging, I think you use the -record-only
>> option to mark the conflicting revisions so they are considered merged and
>> won't be attempted on the next merge.
> OK so something else everyone needs to know when committing code from unstable
> to trunk. I was unaware of that SVN option. This will have to be very
> carefully documented.
> 
>>  I never had to do that, our build engineer did it, but I'm guessing that's
>> the option he used based on the SVN
>> doc.
> And we don't have a build engineer for Apache Flex. Any chance you could ask
> them to either document the process or provide any existing documentation?
The build engineer is gone.  I think we're smart enough to figure out it.
See [2].  It seemed useful.

>> I didn't like the way your list was set up.  Some steps you only do once and
>> some you do often.
> Fine can you please come up with a list step by step that shows what needs to
> be done so that it's clearly understood by all committers.
You clipped it out.  It was in my previous reply.  You do your work in
unstable/develop as normal.  In the Git Branching Model, the release manager
will merge specific revisions or ask you to do so when it is time, or maybe
branch from develop's head, remove some and block the removals.
> 
>> and/or check inFor example, you will do one extra checkout ever (of the
>> unstable branch).
> But you do need two full copies right? As opposed to working in trunk (or
> using multiple short lived branches).
Yes, two copies in the tiered proposal and in the Git Branching Model.
> 
>> Your daily workflow should be no different than working in trunk.
> It is different because you have to merge when moving changesets one by one
> from unstable to trunk rather than just checking in.
In the Git Branching Model, when we decide we want to prepare a release
(which would not be daily) we would cut a release branch from develop and
either take a bunch of known good commits or take from the head, remove and
block.
> 
>> Then when we want to merge back to trunk, you have one extra SVN update
>> since there is an extra branch, the merge, conflict resolution if any, and
>> commit.
> And after the final commit to trunk how do you then make unstable in sync with
> trunk if you needed to resolve any conflicts in trunk?
In the Git Branching Model, you would do the merge, resolve conflicts and
block manually resolved conflicts.
> 
>>  But this may not be daily or per change.  We might batch these up
>> and have the release manager do them.
> IMO that places a rather large burden on the release manager and limits who
> can be the release manager to people who are SVN experts.
I think any person currently in the PPMC is intelligent enough to be a
release manager.
> 
>> I thought there was already a Git mirror of Apache Flex SVN?
> Yep we could use that.
> 
>> Or that we can get one?  And that would be "develop"?
> No it would be both the trunk and unstable. You would merge everything in git
> trunk and them commit changes back to the SVN trunk. We would also miss a lot
> of SVN history if we went down this path.
I think the trunk history may not be any different if we use the Git
Branching Model entirely in SVN because the only commit to trunk is from a
release branch merge operation.
> 
> Thanks,
> Justin
> 
[2] http://www.visualsvn.com/support/svnbook/branchmerge/advanced/
-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: The Git Branching Model: Will it work with SVN?

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> For us, the trunk log said things like "Merge revs 100-150 from Unstable"
> and you would go to the Unstable working copy and view the logs there.
I think that's a significant technical negative to not use this approach.
> 
>> 2. How do we deal with conflicts in trunk when merging changesets from the
>> unstable branch.
> This should in theory be extremely rare in the Git branching model because
> there shouldn't be any independent changes to trunk/master.
We not talking about the git branching model we are talking about using a single unstable branch or so I thought? IMO conflicts will be reasonable common as you need to check in multiple changesets from a single person from unstable to trunk when other people have made changes in unstable as well. If we were checking all of unstable into trunk there would be less issue but you can't do that as some people's changes may not be ready to check into trunk.

> After resolving a conflict by hand-merging, I think you use the -record-only
> option to mark the conflicting revisions so they are considered merged and
> won't be attempted on the next merge.
OK so something else everyone needs to know when committing code from unstable to trunk. I was unaware of that SVN option. This will have to be very carefully documented.

>  I never had to do that, our build engineer did it, but I'm guessing that's the option he used based on the SVN
> doc.
And we don't have a build engineer for Apache Flex. Any chance you could ask them to either document the process or provide any existing documentation?

> I didn't like the way your list was set up.  Some steps you only do once and some you do often.
Fine can you please come up with a list step by step that shows what needs to be done so that it's clearly understood by all committers.

> and/or check inFor example, you will do one extra checkout ever (of the unstable branch).
But you do need two full copies right? As opposed to working in trunk (or using multiple short lived branches).

> Your daily workflow should be no different than working in trunk.
It is different because you have to merge when moving changesets one by one from unstable to trunk rather than just checking in.

> Then when we want to merge back to trunk, you have one extra SVN update
> since there is an extra branch, the merge, conflict resolution if any, and
> commit.
And after the final commit to trunk how do you then make unstable in sync with trunk if you needed to resolve any conflicts in trunk?

>  But this may not be daily or per change.  We might batch these up
> and have the release manager do them.
IMO that places a rather large burden on the release manager and limits who can be the release manager to people who are SVN experts.

> I thought there was already a Git mirror of Apache Flex SVN?
Yep we could use that.

> Or that we can get one?  And that would be "develop"? 
No it would be both the trunk and unstable. You would merge everything in git trunk and them commit changes back to the SVN trunk. We would also miss a lot of SVN history if we went down this path.

Thanks,
Justin

Re: The Git Branching Model: Will it work with SVN?

[Alex Harui <ah...@adobe.com>]

On 8/9/12 5:50 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> HI,
> 
>> So, while the poll is leaning towards an unstable branch, there seems to be
>> a lot of interest in the Git Branching Model described here [1].
> And there's also more interest in multiple branches than a having a single
> unstable branch and also using trunk as the main working area and having a
> branch for each release.
> 
> Before we decide on using a single unstable branch I would like someone to
> confirm the exact sequence of SVN commands needed to work with SVN like this.
> 
> In particular I think these questions need to be answered:
> 1. How do we preserve history of changes (and check in comments) in the
> unstable branch when merging with trunk. I'm not 100% if this is an issue or
> not.
For us, the trunk log said things like "Merge revs 100-150 from Unstable"
and you would go to the Unstable working copy and view the logs there.

> 2. How do we deal with conflicts in trunk when merging changesets from the
> unstable branch.
This should in theory be extremely rare in the Git branching model because
there shouldn't be any independent changes to trunk/master.  But for us, we
occasionally had to hand merge something.  If you ever cut a branch, you
risk having to deal with a conflict by hand-merging.
> 3. How do we keep the unstable branch in sync with the trunk (esp when changes
> need to be made in trunk due to conflicts).
After resolving a conflict by hand-merging, I think you use the -record-only
option to mark the conflicting revisions so they are considered merged and
won't be attempted on the next merge.  I never had to do that, our build
engineer did it, but I'm guessing that's the option he used based on the SVN
doc.
> 
> I did a rough outline of steps here:
> http://markmail.org/message/o4unlhvlfqjprhj7
I didn't like the way your list was set up.  Some steps you only do once and
some you do often.

For example, you will do one extra checkout ever (of the unstable branch).

Your daily workflow should be no different than working in trunk.

Then when we want to merge back to trunk, you have one extra SVN update
since there is an extra branch, the merge, conflict resolution if any, and
commit.  But this may not be daily or per change.  We might batch these up
and have the release manager do them.

In the Git Branching Model, I think we would cut a release branch from the
last known good tag of the last release, then select certain revisions to be
merged into that branch.  I'm not sure it would be right to cut release from
the head of "develop" in our case because new stuff in "develop" will be in
various stages of "done-ness" and don't have to ship in a particular
release, and I'm worried about blowing it when merging back to from
"release" to "develop" if we remove stuff from the release branch that isn't
"done".

In my tiered-branch proposal, instead of cutting a release branch, we would
simply promote certain revisions to trunk and polish the release in trunk,
but it is otherwise the same steps and risks.



> 
>> I am thinking of running a new poll that includes this model, but I want to
>> make sure that there isn't going to be an obvious show-stopper with SVN if
>> it wins.
> Git is much better at handling branches so I would expect there to be some
> issues but IMO there would be less issues than if we used a single unstable
> branch.
> 
>> I also pondered the notion of a variant where SVN trunk is the "master" and
>> we use a Git branch as the "develop" branch.
> You can do this via git-svn
> (http://www.kernel.org/pub/software/scm/git/docs/git-svn.html) but that adds
> further complications. As git is decentralised (ie you work in local copy and
> there is no master) how do you expect the develop branch to be shared? hosted
> on github perhaps?
I thought there was already a Git mirror of Apache Flex SVN?  Or that we can
get one?  And that would be "develop"?  Again, I haven't paid any attention
to the Git side of things.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: The Git Branching Model: Will it work with SVN?

[Justin Mclean <ju...@classsoftware.com>]

HI,

> So, while the poll is leaning towards an unstable branch, there seems to be
> a lot of interest in the Git Branching Model described here [1].
And there's also more interest in multiple branches than a having a single unstable branch and also using trunk as the main working area and having a branch for each release.

Before we decide on using a single unstable branch I would like someone to confirm the exact sequence of SVN commands needed to work with SVN like this.

In particular I think these questions need to be answered:
1. How do we preserve history of changes (and check in comments) in the unstable branch when merging with trunk. I'm not 100% if this is an issue or not.
2. How do we deal with conflicts in trunk when merging changesets from the unstable branch.
3. How do we keep the unstable branch in sync with the trunk (esp when changes need to be made in trunk due to conflicts).

I did a rough outline of steps here:
http://markmail.org/message/o4unlhvlfqjprhj7

> I am thinking of running a new poll that includes this model, but I want to
> make sure that there isn't going to be an obvious show-stopper with SVN if
> it wins.
Git is much better at handling branches so I would expect there to be some issues but IMO there would be less issues than if we used a single unstable branch.

> I also pondered the notion of a variant where SVN trunk is the "master" and
> we use a Git branch as the "develop" branch. 
You can do this via git-svn (http://www.kernel.org/pub/software/scm/git/docs/git-svn.html) but that adds further complications. As git is decentralised (ie you work in local copy and there is no master) how do you expect the develop branch to be shared? hosted on github perhaps?

Thanks,
Justin