Working with branches

Are there any features in IDEA that make working with SVN branches easy?

If not, how are you all dealing with the problem of working on a project with multiple release branches?
Does anyone have a better way of working with branches other than having to recreate the project file for each branch, and maintaining this all separately?
On a project with a couple of modules, this isnt too bad. On a project with 40 modules, this is a pain.

Your thoughts would be appreciated.

N

21 comments
Comment actions Permalink

Hello Nick,

Are there any features in IDEA that make working with SVN branches
easy?


Yes. Particularly in Diana, where integrating a change into another branch
has finally become a very easy operation (just select "Integrate to branch"
on a changelist in the Committed Changes view).

If not, how are you all dealing with the problem of working on a
project with multiple release branches?

Does anyone have a better way of working with branches other than
having to recreate the project file for each branch, and maintaining
this all separately?


We're keeping the .ipr and .iml files in SVN, so there's no need to recreate
the project file and maintain it separately - it's just branched together
with the rest of the sources.

On a project with a couple of modules, this isnt too bad. On a
project with 40 modules, this is a pain.


Our module count is approaching 200 I think, and we're not feeling any pain
at all in this place. :)

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Hello Nick,

We're keeping the .ipr and .iml files in SVN, so there's no need to recreate
the project file and maintain it separately - it's just branched together
with the rest of the sources.

On a project with a couple of modules, this isnt too bad. On a
project with 40 modules, this is a pain.


Our module count is approaching 200 I think, and we're not feeling any pain
at all in this place. :)


Where the problem occurs is when you are a lone IDEA user in an Eclipse shop (as is my case), or in a mixed IDE shop. A "no IDE configuration files in the source code repository" rule is not that uncommon. Plus, committing the .ipr and .iml files to the repository makes the assumption that all developers set up their projects the same way. Again, this is not always true. While it is probably ideal for a team to configure things the same and to share configuration files, that is simply not the reality in many shops.

The solution I have come up with for this issue is to name my project's .ipr and .iml files for a project "projectName-BRANCH#". (for example foo-RB2, foo-TRUNK, etc). My project structure on my disk is /projectName/BRANCH# I then have a script that will copy a project (so it copies the "TRUNK" directory to "RB3" for example), renames the branch # in the .ipr and .iml file names, searchs and replaces the branch name inside the .ipr & .iml files, and then execute a CVS command on the top level source directory to switch to that new branch's tag. I typically run the script on the TRUNK version of the project immediately after the branch is created so the new branches settings and configurations are accurate at the time. Not an ideal solution, but much better than the alternative of recreating a project from scratch. And it has been working pretty well, at least on the projects I am very active on. Where it is not as ideal is when I need to create an IDEA project for a (significantly) older branch. I will typically have to go in and so some settings tweaking in such cases.

0
Comment actions Permalink

My apologies - my initial post certainly could have been clearer, although Ill hit on a point that you raised.

Firstly - our daily development is done on several branches. Current release cycle - Branch B2, patches for previous release cycle, B1, and new features that will be in the next cycle (Trunk). We therefore have three sets of code, being worked on concurrently, depending on issue/feature priority. An ability to quick-switch between these from within IDEA would be great. Code formatting, error highlights etc should be done on "project" level - not at a branch level (which in current IDEA speak would be a 'project') (Maybe Im missing some fundamental feature of IDEA here - Ive not been using IDEA for several months, and I'm a little rusty)

We currently have to create one new project for each branch, and import the module files. This brings me on to my next point:
Many tasks in project/module configuration are a pain if you have more than a handful of modules. For instance, adding an existing library to multiple modules. Changing the base compiler output path (and why does the test compiler output have to be different than the 'production' code - at least provide a way to lock these two together so I dont have to change 2 lines per module, for 40 modules).

When I left last night, I was looking into the environment variables feature of IDEA - it would be nice touch if when I typed a variable name in a path dialog, for example, that the path variable would be highlighted - at least to let me know that the variable had been recognized by the editor.

Most tasks within the project module configuration dont allow me to multi select modules - if I could do this on the module settings, life would be much easier. The only step Ive noticed that works on multiple modules is creating a new library - the settings editor then asks which modules you would like to add the new library to - great!. How about the ability to apply this functionality to existing libraries.

0
Comment actions Permalink

This is more along the lines of what I meant to ask about :)

0
Comment actions Permalink

Hello Nick,

Firstly - our daily development is done on several branches. Current
release cycle - Branch B2, patches for previous release cycle, B1, and
new features that will be in the next cycle (Trunk). We therefore
have three sets of code, being worked on concurrently, depending on
issue/feature priority. An ability to quick-switch between these from
within IDEA would be great.


There's no way for us to make this switching any quicker than "Reopen Recent
Project". These are different projects, different sets of code, and while
we can provide some branch-specific UI for selecting the project to open,
the opening will still take as long as it does now.

Code formatting, error highlights etc
should be done on "project" level - not at a branch level (which in
current IDEA speak would be a 'project')


I don't quite understand what you mean by that, sorry. Code formatting and
error highlights aren't done on project level - they are performed on individual
files you're working on.


We currently have to create one new project for each branch, and
import the module files. This brings me on to my next point:

Many tasks in project/module configuration are a pain if you have more
than a handful of modules. For instance, adding an existing library to
multiple modules.


There's definitely potential for improvement here - if you run into specific
problems or have specific suggestions, feel free to file JIRA issues.

Changing the base compiler output path (and why
does the test compiler output have to be different than the
'production' code - at least provide a way to lock these two together
so I dont have to change 2 lines per module, for 40 modules).


You don't need to change anything if you use the default compile output paths.
Why don't they suit you?

When I left last night, I was looking into the environment variables
feature of IDEA - it would be nice touch if when I typed a variable
name in a path dialog, for example, that the path variable would be
highlighted - at least to let me know that the variable had been
recognized by the editor.


Good idea, also worthy of a JIRA issue. :)

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

You don't need to change anything if you use the default compile output paths.
Why don't they suit you?

Because the team uses ./classes as the output, and they dont use different directories for test vs production - they use different modules for that (or Eclipse projects)



Nick

0
Comment actions Permalink

Hello Nick,

You don't need to change anything if you use the default compile
output paths. Why don't they suit you?

Because the team uses ./classes as the output, and they dont use
different directories for test vs production - they use different
modules for that (or Eclipse projects)


I still don't quite understand. :) Why does the team care about what output
paths you use for your private builds in your own IDE?

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Because we use eclipse and IDEA on the same machine since the Eclipse keymap for IDEA doesn't work that well :-). Apart from some keymappings just not working (which I suspect is due to alternate feature sets between Eclipse and IDEA) some are wrong (Ctrl-F for example was brining up the find & replace dialog yesterday).

While we know we can change these, the Eclipse users on my team don't want the hassle and they don't trust the keymap.

Anyway, since I've been developing Java I've always put my classes in /classes. ./out seems like a throughback to C/C++

I can't honestly recall any Java library I used or product I built that used anything other than ./classes for compiled output.

Furthermore, having 2 directories for class output (prod vs test) makes changing these on large projects time consuming - since there's no way to lock the 2 directory settings to the same value. There are many ways to deal with test vs. production code, and it seems that IDEA is forcing me to use one way, which arguably isn't the most common.

It would be nice to be able to specify the output relative to the module ./src tree (or the .IML location). This way I could specify the output as:
$MODULE_ROOT$/classes, and then do a global search replace in all the module files for the production and test settings.


Switching back to the branching question:
Would it be possible to emulate branch switching using env variables and the 'shelve changes' functionailty? It seems like with these two features this could be possible.

Finally, a source control option to "merge to branch" would be great - if this feature is available now I didn't see it (its not obvious to me).


Regards

N

0
Comment actions Permalink

Hello Nick,

Because we use eclipse and IDEA on the same machine since the Eclipse
keymap for IDEA doesn't work that well :-). Apart from some
keymappings just not working (which I suspect is due to alternate
feature sets between Eclipse and IDEA) some are wrong (Ctrl-F for
example was brining up the find & replace dialog yesterday).


Actually, it is strongly not recommended to share the output directory between
Eclipse and IDEA if they're both used on the same set of sources.

Switching back to the branching question:
Would it be possible to emulate branch switching using env variables
and the 'shelve changes' functionailty? It seems like with these two
features this could be possible.


Sorry, I'm afraid I don't quite understand your idea.

Finally, a source control option to "merge to branch" would be great -
if this feature is available now I didn't see it (its not obvious to
me).


Grab a recent Diana EAP build, select a changelist in Changes | Committed,
select "Integrate to branch" from the context menu.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Nick Pratt wrote:

Switching back to the branching question:
Would it be possible to emulate branch switching using env variables and the 'shelve changes' functionailty? It seems like with these two features this could be possible.
Regards

N

I've been following this discussion and I'm not understanding the issue
- why can't you just have one local sandbox for each branch? Then
switching branches is as simple as switching projects?

N.

0
Comment actions Permalink

Dmitry

Does this integrate to branch functionality work both ways?
For example: Im working on branch B3. I make a change, and commit to the branch. I now also want to commit this change into Trunk. Can I do this without switching branches? (i.e. with the B3 source code in my working copy?)

The dialog is asking for a working copy location, and Im unsure as to why it would need this if I could directly merge from B3-->Trunk

0
Comment actions Permalink

Hello Nick,

Does this integrate to branch functionality work both ways?

For example: Im working on branch B3. I make a change, and commit to
the branch. I now also want to commit this change into Trunk. Can I
do this without switching branches? (i.e. with the B3 source code in
my working copy?)


Yes. It doesn't matter whether you're merging from a branch to the trunk
or the other way round.

The dialog is asking for a working copy location, and Im unsure as to
why it would need this if I could directly merge from B3-->Trunk


It could be possible, but the way we've decided to implement this is to merge
the changes into your local working copy for the other branch, let you resolve
conflicts if any arise (which would be hard with a pure server-side merge),
and then check in the merge result.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

We have tried to use the integrate from branch functionality in IDEA, but we cant seem to figure this out.

Why does the integrate dialog offer us two source paths? If our working copy is, say, Trunk, and we want to merge all changes from some branch, B1, then why cant we simply select "Branch B1", and click on "Merge to local copy". The merge/integrate dialog is a little baffling and non intuitive. Being able to select which revision from Branch B1 to merge from would be helpful.

If this functionality is there now, its confusing.

N

0
Comment actions Permalink

Hello Nick,

Note that the "Integrate to branch" feature available from the context menu
on a committed changelist and the "Integrate Project" feature (which seems
to be the one you're trying to use) are two completely different features
with different use cases.

Also note that merging all changes from a branch automatically requires merge
tracking (keeping history of previously merged changes), which has been only
added in Subversion 1.5 and is not yet supported in IDEA. With Integrate
Project, you need to specify the range of revisions to merge explicitly.
Alternatively, you can use "Integrate to branch" which works on a single
changelist and does not require entering revision numbers manually.

We have tried to use the integrate from branch functionality in IDEA,
but we cant seem to figure this out.

Why does the integrate dialog offer us two source paths? If our
working copy is, say, Trunk, and we want to merge all changes from
some branch, B1, then why cant we simply select "Branch B1", and click
on "Merge to local copy". The merge/integrate dialog is a little
baffling and non intuitive. Being able to select which revision from
Branch B1 to merge from would be helpful.

If this functionality is there now, its confusing.

N

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Dmitry

We are trying to integrate the project - and we also know about the Subversion 1.5 additions for merging. However, right now, we are trying to merge from some specified branch, at some specified revision, into our working copy.
What we dont understand is the layout of the dialog, and why it has multiple selection boxes / text boxes.

Why isnt the merge/integrate project dialog as simple as:

From: Revision: ]]>
To: Working Copy

And then a 'Preview' button and a 'Commit' button


Its not clear from the dialog what we are supposed to be choosing here to execute what in source code control terms is a relatively common and simple task.

0
Comment actions Permalink

this is a svn limitation as far as I know.

The way merging works using svn, is that you specify 2 different states of a project,(a from and a to) and tell subversion to compute the differences between those 2 states AND apply those differences in a, separate, working copy.

So this is actually a "3 way" merge.

0
Comment actions Permalink

So why can't the "to" revision be taken from my working copy, and why do I need to specify two URLs - the begin/end branch is surely going to be the same branch - I can't recall ever wanting to merge a changeset defined between two branches into a third. I guess this would be the equivalent of merging two changesets at once - not something that we consider prudent to do.

By default, I'd expect the simplest possible dialog/operation to be merging changes from one specified branch into my working copy. Unless I'm missing something that should only require a single URL and a starting revision number (for SVN). Default should be to assume I want everything on that branch from selected revision number up to 'head' to be merged into my working copy.

0
Comment actions Permalink

I don't think you want to merge using your working copy as "to" .

Best I can explain is that merge works in 2 steps :
- first create a patch, by computing differences between 2 different revisions (the "from" and "to")
- then apply this patch (to the working copy).

So you can't make the "to" be your working copy, as this would mean applying some changes twice.

Furthermore, I often use 2 different urls in the from and to : eg, use /tags/release-X as from and /branches/release-X (HEAD) for example would create a patch containing all changes done for supporting release X.
THose 2 different urlss are still on the same "branch" though, as usually /tags/release-X would be the "root" of the branch

0
Comment actions Permalink

"I don't think you want to merge using your working copy as "to" ."

Actually, thats exactly what I want to do. The most common use case for branching that Ive experienced, is merging a branch back into trunk.
The second most common is while working on a feature branch, I want to merge Trunk into my branch so I can keep up to date with the changes on trunk.


While I expect the new merge tracking functionality in SVN 1.5 to simplify this a lot, right now, I still dont see the common use case of merging from/to branches to require 2 URL input boxes, and 2 revision numbers.

Eg. 1)
I want to merge a branch into trunk.
I check out trunk to my working copy.
I select the branch to merge from, and the last revision number that was merged, if any ("To-revision" is typically head - I cant recall ever not choosing the latest rev on the branch).
I perform the merge on my local copy, and then commit to Trunk.
Branch is merged.

Eg. 2)
Im working on a branch, and want to get the latest updates on Trunk.
I have my branch working copy.
I select Trunk to merge from, and the revision number (typically Head).
I perform the merge on my local copy, finish off my feature, then do (1) above.


In both of these cases, I only reference one branch URL, and one revision number. Arguably, a second revision number might be required for some use cases, but in my experience, its rare.

So, in the interests of making the GUI as simple and easy as possible for the most common use cases, I think it should be altered to support those use cases and require the least amount of developer input to achieve that goal. I'm certainly not saying that the current functionality should be removed - just moved to an "Advanced" tab.

0
Comment actions Permalink

From my everyday activities, here are some use cases for apparently non-standard merge options.

1) Merge with two different source URL's happens when the starting point is actually a tag. So I might have:

Source URL 1: http://repository/project/tags/last-merge
Source URL 2: http://repository/project/trunk

Actually this is the "standard" way to do merge tracking in previous svn versions without help from third party tools (svnmerge). SVN will compute the differences between the two URL's and apply the result to the working copy.

2) Merge with a non-head final revision. That happens when I'm not merging completely, but just pulling a few changes from another branch.

Both cases happens on a regular basis to me -- actually, I think they happen more often than the simple case where I'm merging all changes from a single source URL.

0
Comment actions Permalink

As you say, merging from a branch into trunk is probably the most common merge operation in svn.

But when svn does the merge, it needs to get the changes to merge, that is, the changes made in the branch. For an example, look at this figure. In this example we need to get the changes made in r343 merged into our working copy of the trunk.

So, to get these changes, the diff between the branch point and the trunk of the branch must be retrieved. This is crucial to understand. That is, we must know from where and when the branch is done in addition to the trunk of the branch. This translates into having to specify two URLs and at least one revision (for the branch point).

Now there is a possibility to retrieve the branch point automatically when specifying the branch URL. By using functionality in svn that show all history until it reaches the point a svn copy is made, we will get both the branch point's URL and revision. The problem with this solution is that it might be other copies done between the branch point and the branch's trunk, for example when renaming (svn does not have native renaming; it is done by a copy and a delete) a directory higher up in the directory structure. In the example used above, renaming calc would be an example of this.

So, in the interest of making the GUI as simple as possible, one solution would be to have the possibility to enter two URLs and two revisions, but prefill the revision for the right URL (svn terminology for the place one is merging from) with HEAD and provide a "Calculate" button that will do a svn log which finds the branch point and fills out the left URL (svn terminology for the branch point) and revision from this branch point.

Then the developer must make sure the values filled out is correct, for example by looking at the found branch point (svn log -r revision url), before doing the merge.

In addition, it would be helpful to have more explanations around the operations done by this dialog box. It is quite cryptic as it is.


Regards,
Stig Kleppe-Jørgensen

0

Please sign in to leave a comment.