Vault 4.0 Merge branches

[mlippert]

Eric,
I was wondering if you could share some of how you're hoping to improve Vault's merge capabilities in 4.0.

I've attached a diagram that illustrates a section of our source tree showing branches and merges. (We have more release branches and more development branches, but these were the ones I was most interested in when I drew the diagram, and it gets the point across).

• A better determination of the "base" file, particularly when merging back and forth between 2 branches would be the biggest win.
• Better control over the order of operations (move/rename/delete/edit) so that if a file is renamed and then moved and then edited (or some other order) it doesn't require user intervention to apply those operations to the correct file.
• Recognition of keyword expansion, so that it doesn't create an unnecessary conflict (this easily causes the majority of my conflicts during a merge, each of which I must manually resolve).

A co-worker and I were just thinking about how to determine the "base" file after previous merges. We didn't spend a lot of time on it, but I'm curious what the issues are.

Mike

[ericsink]

Vault 4 only allows merge between folders where one folder is a branch of the other. This helps, because the correspondence between files is easy to figure out when we know that there was a point in the past when they were identical.

However, it makes bidirectional merge harder.

So Vault 4 provides full support for merge history. It keeps track of merges which have already been done, in both directions. In fact, it draws a graphical display of changesets which have been applied from one branch to the other.

Vault 4's merge tool is changeset oriented. When changes are merged into the target, they are grouped the same way that they were originally grouped in the origin.

Bottom line: Figuring out the base file is straightforward when the operation is changeset oriented and you know everything about the branch relationship between the two folders.

Drop me an email if you want to talk further?

eric@sourcegear.com

[mlippert]

That sounds great Eric. Thank you for sharing.

Keep in mind the keyword expansion issue when testing

I may drop you an email when I get a chance later.

Thanks again,
Mike

[GregM]

Is this going to completely replace the existing merging? I think this is great, and it's going to make things much easier. However, there are times when it would be useful to be able to take a set of changes and apply them to a set of "unrelated" files. It's probably not a huge deal if this isn't available, as I think I've only run into this once.

[ericsink]

Is this going to completely replace the existing merging?

Yes. Maintaining both is not an attractive idea, and unfortunately the current design is optimized for an uncommon case.

[GregM]

Oh well. I'd rather have the new one than the old one.

[ismangil]

Recognition of keyword expansion, so that it doesn't create an unnecessary conflict (this easily causes the majority of my conflicts during a merge, each of which I must manually resolve).

+1 for the keyword expansion ignore. We don't use merge very often (we branch for releases only), but when we do, keyword expansion is the number one cause for conflicts.

[ericsink]

Recognition of keyword expansion, so that it doesn't create an unnecessary conflict (this easily causes the majority of my conflicts during a merge, each of which I must manually resolve).

+1 for the keyword expansion ignore. We don't use merge very often (we branch for releases only), but when we do, keyword expansion is the number one cause for conflicts.

Making merge branches play nicely with keyword expansion is part of the plan for 4.0.

[rgrimard]

Vault 4 only allows merge between folders where one folder is a branch of the other. This helps, because the correspondence between files is easy to figure out when we know that there was a point in the past when they were identical.

However, it makes bidirectional merge harder.

So Vault 4 provides full support for merge history. It keeps track of merges which have already been done, in both directions. In fact, it draws a graphical display of changesets which have been applied from one branch to the other.

Vault 4's merge tool is changeset oriented. When changes are merged into the target, they are grouped the same way that they were originally grouped in the origin.

Bottom line: Figuring out the base file is straightforward when the operation is changeset oriented and you know everything about the branch relationship between the two folders.

Drop me an email if you want to talk further?

eric@sourcegear.com

I've been searching the forums for the "merge changeset" functionality. This was the most relevant post (from 2006) I could find. Is there such a thing as "merge changeset" in Vault 4.0? I'd like to avoid the "mass merge" scenario while merging Widgets 1.1 into the 2.0 code base. By mass merge, I mean I'd rather not merge an entire solution or even project at one time. Instead, I'd rather allow individual developers to merge their changesets from 1.1 into 2.0 on an ongoing basis as we fix defects.

Is this already in 4.0?

Also, you mentioned a graphical display. Does that exist?


Thanks
Ryan

[jgagnontt]

Bump.

I'm using version 4.1.4 (18402); I have several folders that were branched off of each other, and their histories need to be merged so that all prior versions of the code are in one place. Was this history merge feature ever implemented, and if so does it still exist in this version? I can't seem to find it.

I did attempt a folder merge and it didn't preserve the history; all it did was show the existing history up to January (which is when the destination folder was last updated) and then a merge with today's date.

Help? Anyone?