Why aren't branches used on Forge?

[ArsenalNut]

I've been wondering for a while why branches aren't used on Forge. I wanted to create a branch to look at how some of the keywords are handled, but wasn't sure they were allowed. The conflicts created by the modifications made by DoubleStrike and Max MTG would have mitigated to a large degree if they had both been developing in branches.

I am not trying to disparage anyone's work. I love the changes to the deck editor. I am just frustrated because I cannot test a half dozen or so card I scripted this afternoon after I updated.

It just seems like good policy to make large scale changes in a branch. The branch can be kept updated with minor changes from the Trunk. It would also allow alpha testing without effecting the fragile trunk.

[Max mtg]

Doublestrike was developing quest-related stuff, then found the codebase has changed and his solution no longer worked, so (full of emotions probably) he commited a broken build. Branches don't fix such problems and they have to be merged anyway

Looks like there will be a rollback to 10193

Also, you can update your copy of code to a certain revision, 10193 for instance, while keeping the res folder in HEAD revision

[ArsenalNut]

Doublestrike was developing quest-related stuff, then found the codebase has changed and his solution no longer worked, so (full of emotions probably) he commited a broken build. Branches don't fix such problems and they have to be merged anyway

Looks like there will be a rollback to 10193

Also, you can update your copy of code to a certain revision, 10193 for instance, while keeping the res folder in HEAD revision

I disagree. If DoubleStrike had been working in a branch, DoubleStrike could have committed incrementally to the branch and still keep in sync with changes to the trunk. Then when DoubleStrike realized the branch no longer worked because of other changes, the trunk remains intact and DoubleStrike's work is saved in a branch that can be worked on further if so desired.

A conflict could occur with branches for instance if your changes were in branch that DoubleStrike wasn't aware of. Then there would be in an issue when both branches were merged with the trunk but this largely a communication or coordination issue, which is a whole different topic.

I am not trying to pick on DoubleStrike. To me this incident is a classic example of why you want to use branches.

Thanks for the tip about keeping the code at a certain revision. I had figured out how to roll back the whole project but just rolling back the src would solve my issues with test decks that have cards that no longer existed in the rollback.

[Rob Cashwalker]

Our devs all have various skill levels and branching is one of those advanced things that can make it very confusing for some of us... which is why Git kinda sucked for us.

As long as a dev updates their code prior to a commit, they have the opportunity to fix it to match with other changes before uploading.

[jendave]

Our devs all have various skill levels and branching is one of those advanced things that can make it very confusing for some of us... which is why Git kinda sucked for us.

As long as a dev updates their code prior to a commit, they have the opportunity to fix it to match with other changes before uploading.

I agree with Rob on this. Branches need to be used with great care. In my experience, branches that are intended to be merged back into the trunk should only be used for small or siloed changes. Large merges are almost always very painful. They require lots of skill and coordination.

Branches are fine for cutover development, where the old codebase is copied into a branch and supporting patches are applied. New major development would then occur on the trunk and possibly not be released for some time. Again that would still take quite a bit of coordination to ensure proper scoping of features that would go into the trunk.

Git is the best SCM I have seen in regards to how it allows merges between branches. That said, Rob is correct in that even Git required a level of skill and plugin support (Eclipse had some Git issues) that was not conducive to Forge.

[ArsenalNut]

I am used to working in an environment with branched development so that's what prompted the question.

If I am comfortable using branches, is it all right if I use them? Most of the changes I've made have been small so I've been able to make a fix, test it, and commit pretty much in one sitting. I want to look at how some of the keyword words handled which will take me longer. I'd like to be able to check in revisions without messing up the trunk.

[Max mtg]

I don't know how to use branches, so I keep several copies of the project check out, one being actually a branch and other current version where I can fix bugs (and then transfer fixes to my brach by SVN-updating it)

[slapshot5]

I don't know now to use branches, so I keep several copies of the project check out, one being actually a branch and other current version where I can fix bugs (and then transfer fixes to my brach by SVN-updating it)

I do the same thing.

-slapshot5

[jendave]

I am used to working in an environment with branched development so that's what prompted the question.

If I am comfortable using branches, is it all right if I use them? Most of the changes I've made have been small so I've been able to make a fix, test it, and commit pretty much in one sitting. I want to look at how some of the keyword words handled which will take me longer. I'd like to be able to check in revisions without messing up the trunk.

Feel free to use branches.

[jendave]

I don't know now to use branches, so I keep several copies of the project check out, one being actually a branch and other current version where I can fix bugs (and then transfer fixes to my brach by SVN-updating it)

I do the same thing.

-slapshot5

I do this as well. I keep a SVN copy for working on the Maven build logic since that has SVN dependencies. For other development, I use git-svn to clone the SVN repo into a local git repo. I have a tracking branch which keeps as close as possible to the trunk and also keep several local branches depending on what I am working on.

[ArsenalNut]

I do this as well. I keep a SVN copy for working on the Maven build logic since that has SVN dependencies. For other development, I use git-svn to clone the SVN repo into a local git repo. I have a tracking branch which keeps as close as possible to the trunk and also keep several local branches depending on what I am working on.

This looks like the best option for the way I'd like to work. I've been reading up on git-svn. Could you tell me what tools you're using? From what I'm finding, it doesn't look like Egit supports git-svn yet. Are you committing from your local git repo to the Forge SVN repo?

[jendave]

I do this as well. I keep a SVN copy for working on the Maven build logic since that has SVN dependencies. For other development, I use git-svn to clone the SVN repo into a local git repo. I have a tracking branch which keeps as close as possible to the trunk and also keep several local branches depending on what I am working on.

This looks like the best option for the way I'd like to work. I've been reading up on git-svn. Could you tell me what tools you're using? From what I'm finding, it doesn't look like Egit supports git-svn yet. Are you committing from your local git repo to the Forge SVN repo?

I use command line almost exclusively for both SVN and Git. I use svnX when I do some SVN admin work (such as setting up the repo). I sometimes use GitX to see the status of my various branches. I have never liked the plugins for Eclipse.

I am committing from my local git repo into Forge SVN. The basic workflow is
1. Get latest changes from svn: 'git svn fetch'
2. Reset local repo: 'git svn rebase'
3. Make edits, changes etc.
4. Do 1. and 2. again to make sure you have the latest changes.
5. Commit changes: 'git svn dcommit'

Since I use git branches, there are a few more steps, but that is handled within git, not the git-svn toolset.