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.
Related
Im not an expert at git, but I have a iOS project that has code that I would like to reuse. I will be switching out images and a little data to make each application different. I know you can do this with the targets approach but I wanted to keep everything seperate and out of the original xcode project. So my question is, do I create a branch for each new project, and if so what is the correct terminology or command to grab bug updates from the original code base into my new branch from the main branch? The new branch will never commit back to the master branch also.
I strongly suggest you make different repository for each project, not different branch.
If you have one repository for several projects and for each project different branch, very soon you'll have a mess in your repo.
Also, if you fix a bug on part of code which you want to reuse, you'll need to merge the fix with all branches which use that code.
So, I think the better and much cleaner approach would be to create different repositories for each project, and code which you want to reuse you can add as a git submodule.
So, you'll have repository for your iPhone project then submodule for your shared library, Restkit, and so on...
You will want to review the git branching section of the online reference at GIT-SCM. At a high level you will want to look at merging the various branches. Xcode 5/5.0.1 helps you immensely by using the menu Source Control > Working Copy > Project Name > New, Switch, or Select Merge Into/From Options...
I am working on several projects in Eclipse. The projects are checked out from an SVN repository. The projects also depend on each other. Currently, if I want to commit them, I have to mark each project and then call Team -> Commit.
Is it possible to commit everything without selecting particular projects? That's quite annoying. It is especially difficult to remember which projects were changed today and which were not. I tried doing this with working sets but I do not see any option of committing them.
Any ideas?
You can only commit them together if they are all part of the same working copy. If you checked each project out individually via Eclipse, this will not be the case.
Unless there's very tight coupling between the projects, you normally should not be committing multiple projects at once. It's not about making things less convenient to you, but about making your commits smaller, self-contained "units".
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
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.
I have a folder where I keep checked-out version from Aptana Subversive SVN plugin. I have another folder where the checked-out copy from Eclipse resides. Both, Aptana & Eclipse, are using the same repository. Though the repository is the same, but I am using two different working folders. Sometimes I use Eclipse to work with the same set of files in the repository and sometimes I use Aptana.
I want a tool that can synchronize the two working folders automatically. Is there any free tool?
Actually, SVN is the tool to do just that. If you fight SVN, you will run into trouble, because you might not have both working copies updated to the same the same revision, the merge tool messes up the hidden .svn folders and whatnot.
Why do you think you need to manually synchronize those two working copies? If you want to work on both simultaneously without disrupting other's work because you keep checking in half-baked things, consider working on a branch. Doing so, you make use of SVN, which was designed to keep two working copies in sync. If you're done with whatever you're doing, merge that branch into the trunk (or whatever branch you were working at) and throw it away.
If you feel like all this checking in might make your repository become too big, get a bigger disk to store it on. The very first time you or that tool messes up manual merging, it would have payed off. If you're afraid of bumping SVN's revision count without doing actual work, get a grip.
Araxis Merge has automated merge.