We are in a transition from source control Clearcase to SVN and we cannot find a similar workflow in svn as we had in Clearcase.
In Clearcase we had one integration view from where the builds were done. Each developer also has its own "developer view" where development is done. Periodically (when some work item is done), code from dev views is delivered into integration view. Then both views were synchronized together and we were good to go. The "developer view" can be used for years in this scenario.
We try to achieve the same workflow in SVN using branches but we are having the following problem:
If, as mentioned in the svn doc, we
merge into the trunk using the
--reintegrate flag, our branch become useless and need to be
recreated. It is not pratical,
especially when using Eclipse (we do
not want to recreate our workspace
or even deleted the "old" project
because the launch configuration is
lost).
If we merge without that
option, we end up, few commit/merge
later with various unexpected
conflict like "local obstruction,
incoming add upon merge" even if the
file was added only once.
So my question is how can we have one branch per developper? If it is not possible, how do you work with Eclipse, SVN and branches. One last thing, we want to keep the trunk pristine, so working directly in the trunk is not and option :-)
Thanks for your insight,
-Martin
Generally, a branch per developer is frowned at and is definitely not the recommended flow in SVN. In DVCS like Git, Hg, developers can have local branches to work on and such branches are cheap. Maybe you can consider using git-svn or even shift to Git / Hg and have less painful merges.
Related
I don't understand something that is happening on my Eclipse and I am wondering if this is my Eclipse problem or if this is actually a feature. I have a trunk and a branch. On the repository they are the same so no changes have been commited since I created the branch. After making the branch I switch on my workspace the project from trunk to branch. Then I started working and changing on the branch. Suddenly I wanted to see something on the trunk because I got lost in my changes. So I switch to the trunk. I was surprised when Eclipse did not remove my changes and it was as if no switch was made. The changes continued being there.
Is this normal?
Can someone explain?
Thanks,
David
This is perfectly normal, and the way the svn switch is suppose to work.
Here's a common scenario. You're working on trunk, and realize that your changes should be applied to a branch instead. You simply do switch and you are now on a new branch and your changes are now applied to the new branch. Many times, I'll be working on one stream (a branch or trunk), and realize that my changes are too experimental and big to go into the current development stream. I'll create a new branch and switch to it.
There is no reason with gigabyte fast disks, and gigabyte networks to be skimping on working directories. I tell developers to dedicate a working directory for each project and branch. Otherwise, if they keep switching back and forth between various development streams, they're going to forget and do development in the wrong place.
With almost any svn client you can:
check out a project
make some changes
switch back and forth to any truck/branch
preserve your changes along the way
In other words, nothing specific to eclipse here.
see: svn switch
I prefer to have separate eclipse projects per branch and also change the project name to something like myProject-24 so when the branch is checked out again down the road, the default project name has some branch identifier on it.
This also enables you to make changes on a per branch level and do single commits across the branches; even if they're in discreet eclipse projects.
The functionality you are looking for can be reached by doing the following
Right Click on the folder that should be replaced
Click on "Replace With ..." from the context menu
Click on "Branch ..."
Select the branch you want to take a look at from the dropdown box
ATTENTION: This is replacing your local changes. It is not possible to reverse this.
Greetings
Tobi
For git, "A successful Git branching model" gives great advice.
I want to give Fossil a shot, and it seems to be very compatible with git (the most striking difference (of SCM features) I noticed so far is the denial of git-rebase's functionality, partly mitigated by the shunning feature). So can the git workflow be simply adapted 1:1 or is a different workflow more recommendable? E.g. how can the additional features of fossil (integrated Issue Tracker and Wiki) be integrated?
(source: nvie.com)
As I know, fossil use auto-sync mode to reduce the the branch which possible make developer busy.
So every developer setup auto-sync with main backup repository. Then when want to enhance a feature, just set a branch on check in. When the feature workable, merge back to trunk.
If you want to let all developers shared the same branches tree for review purpose add --private option when clone.
So, in the picture which you gave. We can treat 'develop' as 'trunk'. And all others as --branch option of commit.
When we wan to develop under one branch, just 'fossil update
Suppose I have the following senario:
Trunk is my main development line where programmers commit to when done.
Branch V1.0 is a branch I created when releasing version 1.0.
The programmer is working on the trunk but needs to switch to the branch in order to fix bugs.
When switching back to the trunk Subversion will give me the latest in the SVN repository which does not include the recent changes.
So, in order to switch he will have to commit what he has because otherwise the changes are "lost". I know they are still kept in the local repository but it would still mean restoring them one by one once he switchesback.
Am I missing something here?
Edit:
Now I am thinking down these lines:
Each programmer would have his own "private" development branch off of the trunch. He could commit to there whenever he wants. When he has finished what he has written he can them merge it into the trunk. He starts again for the next assignment.
If at any point he is required to fix a bug in some other release he can just commit to his own private branch, fetch the odl release and fix it. Then, after committing the changes to the fix, he can easily switch back to his own development branch.
Would that work?
I think that subversion is not thought for switching as you described. A solution would be to have two workspaces, one for the branch and another one the trunk, so you can switch from one to another without problems. I know it is not a nice one.
Consider switching to a version control tool that is better suited for your approach. My own suggestion is Mercurial, coupled with MercurialEclipse. The only drawbacks I'm aware of are that Subversion is better suited to store binary files and that Mercurial's subrepositories don't work so well as Subversion's externals.
In Mercurial your programmers would be able to commit their changes to their private repositories, merge and commit locally again, and then push the resulting changes to an official repository, from which other programmers would pull them into their own private repositories.
The best solution for such purposes is to have two separate working copies. One for working with trunk and one working with the branch.
Update: We ended up using a process very much like this schema (thanks to neuro for the link). We massaged out repository into a state where default is stable (and has the same code as our production environment), we have a dev branch, feature branches for new stuff and use release branches for releases. All seems to be working perfectly.
Backstory
Our team has recently switched from using SVN (using ToroiseSVN Windows client) to Mercurial (using TortoiseHg Windows client) for version control. We have successfully exported our SVN repository and imported it into a Mercurial repository.
We now have a Mercurial repository where we can see the entire history of revisions (changesets in Mercurial).
How we did it in the old days
Life was simpler in the old days; our development process was not really multi-stream like it is now. The trunk was used to hold all code - even changes that were still in-flight (as long as it didn't break the trunk). When it came to managing releases with SVN, we would checkout the trunk (which holds all code), revert the individual changes we didn't want as part of the release, and create a tag for it.
Cherrypicking the code we want with SVN was easy. Bug-fixing previous releases and ensuring it was part of the trunk was simple too.
What we are doing now
In Mercurial, we need to be able to get a snapshot of the "trunk" (default in Mercurial) with individual changes reverted out. We can do this using hg revert.
To snapshot this, we have created a "named branch" - let's call it Build-4.0.1 for now.
Where the challenge arises
Development continues on default as normal when a bug is found in Build-4.0.1. Let's assume the bug is in one of the reverted files. We change the code from the branch for Build-4.0.1, create a new "named branch" (Build-4.0.2) and want to merge it back into default without pushing the reverted code over the top of newer code. How can we accomplish this?
Alternatively, is there a better workflow for managing the releases and our code in Mercurial? I quite like the look of this wonderful SO answer on managing release branches, although I am not sure how we can transition to it from the state we are in now (with in-flight stuff in default).
Note: I have looked at the Transplant extension, but haven't used it yet - could it be part of the solution to this challenge?
Well, to begin with, your use of revert seems strange to me. Usually it is used to revert modifications done to the working copy back to the version of the repository.
The usual way to get the working copy to some point backward is to update :
hg update -r 1234
from there, you can tag, modify, commit, etc.
To merge back you only have to merge your release branch to the default branch. It will work like a charm, unless it is to different/old a release.
Transplant works fine, but do something a bit different from merge : it take your changeset as a "diff" and apply it as a new modification.
To manage your releases, you can look this other answer (by me) :
How to use mercurial for release management?
What we use is a clone / main branch that holds the most stable version, which is released at some points. On this clone : branch, we can fix critical bugs (hotfix). In parallel, we use a dev clone / branch to develop. The hotfixes are merge as soon as completed from stable to dev. When the current development is done, we merge the dev on stable / default.
This schema is pretty good to understand things :)
Good luck !
Going through all the changes and taking out the ones you don't want is not a common way of creating a release, to put it mildly. The Common Branching Patterns section in the SVN book suggest some more popular work flows:
release branches: create release branch from unstable trunk, fix bugs to stabilize it, cherry pick bug fixes between them while the branch is in maintenance mode.
feature branches: keep the trunk stable and ready for release by only merging in the feature branches that you want
The second one is probably the best fit here, because it gives you a place to put experimental or risky changes until you feel confident about them - these are the changes you would have reverted before a release in your old workflow.
Both of these branching patterns should carry over just fine to mercurial. In case you go for the first approach, note that mercurial (since 2.0) now has a graft command, you no longer need the transplant extension.
So my team is just starting to use branches on our project, and we've run into an organizational issue concerning the way Eclipse/CVS handle branches and projects. My question is this:
Is it possible to ensure that multiple projects are always synched to the same branch with CVS in Eclipse?
Here's a simplified scenario:
Two projects: ProjA and ProjB, and two branches: Dev and Release.
So let's say both projects are synched to Release in my workspace, and I decided to add a new feature. I only anticipate that this feature will touch ProjA, so I naively branch only that project to Dev. So now my workspace is inconsistent.
After a few hours of work, I realize that I need to make a small change to ProjB, so I pop open the file in question and make my change, forgetting to sync it to Dev.
Later, after my changes are complete, I commit them. Now, I've just committed the changes in the first project to Dev, and the changes in the second project to Release. Woohoo, broken build!
A solution to this problem would either:
not have let me sync the two projects separately
not have let me commit to two branches at the same time
Now, in the real world, we have about 30 projects, and a number of developers working on feature branches, many of whom seem destined to use branching to break the build any way possible. I'd like to remove some of those ways.
Is changing vcs an option? Having recently transitioned at my work from cvs to mercurial, I don't think I could go back. I think that any of mercurial, git or bzr would solve those issues.
After much trial and research, it seems that because of the way branches are handled in CVS (that is, on a per-file basis), a scenario like the one I seek is not possible (at least not without some tool special-built to this purpose).
We ended up just going with a soft solution: By changing the color and format of the CVS label decorations in Eclipse to something more striking and isolated, it's much easier to casually identify which branch a project (or file) is synched to.
The Eclipse settings are found at Team > CVS > Label Decorations > Text Decorations and General > Appearance > Colors and Fonts > Basic > Decoration Color.
And, of course, implementing some best-practices along the way.
There are two approaches you can take here.
Name your Eclipse projects after the branch they're created. So if you're working on a feature branch for ticket number 123 dealing with ProjA you check out your Eclipse project as ProjA_123 (or ProjA_Dev if you wish). You can call your release branch ProjA_Release.
Alternatively you could maintain separate Eclipse workspaces for each branch.
So long as you have some system to identify which branch your working checkout is from, you should be fine.