| Isn't there a "best practice" for handling branches with eclipse's team feature? [message #290367] |
Wed, 24 August 2005 15:26  |
Eclipse User |
|
|
|
Originally posted by: alexander.ruehl.tietoenator.com
Hi folks,
I hope, I'm right in this forum with the topic, otherwise I'm grateful for
a link to a better one.
We are hotly discussing the problem what is the best way to deal with
branches when doing bugfixes for a project.
One side is arguing, the developer should go to the top of the eclipse
project and branch from there.
The other side is arguing, the developer should branch each edited file
separately with the same branch name.
In my opinion, the 1st method has the downside, that the branch is
assigned to hundreds of files which are not touched by the fix and that
merging them into the head again after testing the branch produces lots of
conflicts.
The 2nd method has the downside, that eclipse's team feature doesn't show
the branch (one has to pick it by "configure tags"), that tags are mixed
and that versions can't be compared or replaced completely.
Can someone help us out by a killing argument for or against one method?
|
|
|
| Re: Isn't there a "best practice" for handling branches with eclipse's team [message #290426 is a reply to message #290367] |
Thu, 25 August 2005 12:53  |
| Eclipse User |
|
|
|
Originally posted by: automatic.javalobby.org
You have to be more specific as to the back-end provider. Different version control systems may well handle this differently.
Branches are generally set up so that fixes can be made on a maintenance stream, whilst on-going (and potentially volatile) development can go on ahead. It is usually the case that this is not done on a fix-by-fix basis; instead, when a fixed version is shipped, a branch is created at that point for everything in the codebase. Most version control systems don't actually duplicate the code, but do a copy-on-write or tagging mechanism that allows unchanged files to be the same for the branch and non-branch versions.
You'll find it much harder if you think of each file being branched; apart from anything else, you've then got no idea whether an up-to-date version of a file is associated with the main trunk (HEAD) or the bugfix version(1.0.1).
There's an article on specifically using CVS with branching at http://www.eclipse.org/articles/Article-CVS-branching/eclips e_branch.html
There should be no danger with doing merges in from a branch; every sensible version control system will only do the merge of the changed files since the branch point, and will not attempt to merge every file on the branch.
So the top of the Eclipse project is the right place to make a branch, and the misunderstanding that all of the files are 'touched' by this branching process is false. Note that there's an outside possibility that you might be using a version control system that's hideously badly implemented; in which case, I'd suggest that you move to something more sensible like CVS or SVN.
|
|
|
| Re: Isn't there a "best practice" for handling branches with eclipse's team [message #290449 is a reply to message #290426] |
Thu, 25 August 2005 15:08 |
| Eclipse User |
|
|
|
Originally posted by: eclipse3.rizzoweb.com
Alex Blewitt wrote:
> You have to be more specific as to the back-end provider. Different
> version control systems may well handle this differently.
>
> Branches are generally set up so that fixes can be made on a
> maintenance stream, whilst on-going (and potentially volatile)
> development can go on ahead. It is usually the case that this is not
> done on a fix-by-fix basis; instead, when a fixed version is shipped,
> a branch is created at that point for everything in the codebase.
> Most version control systems don't actually duplicate the code, but
> do a copy-on-write or tagging mechanism that allows unchanged files
> to be the same for the branch and non-branch versions.
>
> You'll find it much harder if you think of each file being branched;
> apart from anything else, you've then got no idea whether an
> up-to-date version of a file is associated with the main trunk (HEAD)
> or the bugfix version(1.0.1).
>
> There's an article on specifically using CVS with branching at
> http://www.eclipse.org/articles/Article-CVS-branching/eclips e_branch.html
>
>
> There should be no danger with doing merges in from a branch; every
> sensible version control system will only do the merge of the changed
> files since the branch point, and will not attempt to merge every
> file on the branch.
>
> So the top of the Eclipse project is the right place to make a
> branch, and the misunderstanding that all of the files are 'touched'
> by this branching process is false. Note that there's an outside
> possibility that you might be using a version control system that's
> hideously badly implemented; in which case, I'd suggest that you move
> to something more sensible like CVS or SVN.
Based on 9+ years of experience, I agree with the recommendations and
reasoning above.
Just wanted to give a re-affirmation so that you have a sense of
consensus - branching the entire repository/module at release time is
definitely the industry best practice, especially when it comes to CVS.
HTH,
Eric
|
|
|
|
Powered by
FUDForum. Page generated in 0.02581 seconds
] 
Search
Help
Register
Login
Home
