Can you merge branches via the command line?

[CdrJameson]

...because it'd let me write a script to automate a lot of donkey work I'm currently doing by hoof, er, hand.

[Beth]

Unfortunately, we don't currently have a way to run the merge branches via command line. It's an entire wizard with multiple steps to it.

Are you on a machine that can't run a Vault CLC?

What kind of stuff are you performing by hand?

[CdrJameson]

Hi Beth,

What I'm currently doing is merging a set of changes from our development branch into our release branches.

The process goes something like this:
- Find a list of the version numbers I need to merge (run history with a search for the task ID in our comments)
- Note this down on a piece of paper

Then, for each change,
- Run the merge branch wizard
- Skip the instructions
- Select the development branch source, the release branch target.
- (Wait while target folder is scanned) - skip screen whatever the result
- (Wait while full list of all the changes ever made is downloaded)
- (Wait a bit more)
- (Continue waiting - there are over 9000 versions)
- Select the earliest numbered change to merge from the list on my piece of paper
- Skip changing any settings
- Wait while it retrieves moves and shares, then click next
- Wait while it retrieves renames, then click next
- Wait while it retrieves files from server, then click next
- Click OK on the adds/deletes/edits
- Click the done screen
- Click 'finish'.
- Manually resolve any merge problems

When this process is complete I have a single change set and the whole lot can be checked in and lo! the merge is done.

It's not a difficult process, but boy is it laborious. At each stage I have to at least go back to it to press a 'next' button, or the whole process grinds to a halt.

It also does a lot of pointless, time consuming repetitive work. For example it takes several minutes retrieving the entire change history of the repository for each change even though I already know the version numbers of the changes I want to merge.

I'd love to just be able to type:

vault merge-branches $/HEAD $/version11 revision:9576

and only have to come back to it to read the process log and resolve any merge conflicts.

[Beth]

What you want makes sense for your case. Would it help if you wouldn't have to wait as long for the change set by having a filter that limits how many changes you get? That's one idea that's been on our radar.

As far as skipping a lot of the extra stuff, I'll need to put in a feature request.

[GregM]

That's one idea that's been on our radar.

That's been on our radar??????

Jeff said this in MARCH:

Vault 6 will be adding a Merge Branches feature to filter history by dates. Also, I will be looking at other requests for merge branches, for example, labeling "source" folders after the merge, comment formatting, and skipping wizard pages.

PLEASE don't tell me this has been dropped AGAIN. It's one of the very first things I requested when we moved to Vault, almost 7 years ago. It's been almost 6 years since Eric said that the merge branches process was being redesigned to be more intelligent, and to remember its history, and here we are with the same original slow interface with no intelligence.

http://support.sourcegear.com/viewtopic ... 61&p=22004

[Beth]

I didn't put it that way to say it's been pushed back. That was just a bad phrasing to use on my part. The important part of that paragraph was to find out if that would help the user's situation at all.

[CdrJameson]

Yes, that would help a lot as it's by far the slowest part of the process (and completely pointless, as I know which revisions I want already)

[BSayatovic]

Unfortunately, we don't currently have a way to run the merge branches via command line. It's an entire wizard with multiple steps to it.

Pardon me interrupting the thread, but this thread touched on the every thing I'm struggling with. Difficulty in merging.

• Is it really NOT possible to do a "dry run"
• Is it really NOT possible to do a merge in a single, atomic commit (moves, renames AND file changes)?
• Is it really NOT possible to do this from the command line?

Surely I'm wrong. SourceGear touts how much better they are than Subversion. But as I read that description, it occurs to me that SourceGear has entirely missed the point of how Subversion does it: precise, mathematical merges in a single, atomic step with dry-run capability.

[Beth]

Dry Run: Vault doesn't automatically check in the results of a merge branches, so that allows you to go through the merge branches and see what results you would get first before checking any changes in. If you don't like the merge branches result, you can undo any changes from the Vault Pending Changes window. If you do like your results, then you would check the changes set in.

Atomic Commit: Vault does have the ability to perform an atomic commit, even on the results of a merge branches.

Command Line: Merge Branches cannot be run from the command line.

[BSayatovic]

Atomic Commit: Vault does have the ability to perform an atomic commit, even on the results of a merge branches.

Beth, the Vault Standard Client Help's Merge Branches topic states for both "moves and shares" and "renames":

Code: Select all

The [move/rename] operations will be performed and committed to the repository as the wizard proceeds.

I was under the impression that these changes were committed BEFORE proceeding to the normal changes, not added to the pending change set. I consider moves, shares and renames to be changes just like file changes, and I'd like them all to be committed atomically together.

[Beth]

Sorry, I missed addressing that part.

You are correct that with the Moves and Renames, those are committed during the merge. There are two screens that show what Moves and Renames were found so that you are aware of those items and it gives you the option to uncheck those actions to stop them. The actions are then given a comment related to the Merge Branches.

I can put in a feature request for different functionality if you would like.

[BSayatovic]

I can put in a feature request for different functionality if you would like.

Beth, yes. I think I could summarize the two, possibly mutually exclusive, features like this:

• Use a single, atomic commit for moves, shares, renames and file changes (not a two-step commit)
• Offer a "dry run" preview of what all is different so someone can be aware of what they're in for before they get to step 2

[Beth]

On the preview, what are you specifically looking for? Also can you tell me what you hope to gain from it?

Why I'm asking is that I can see some downsides to it. I can still put in the feature request, but I think I'm missing what you're envisioning.

Once the moves, renames, and shares are added to the pending change list at the end, you will have a list of every change that would happen because of the merge branches listed there and not checked in. The changes to the inside of a file are already listed in the pending changes window. A user would then just check the list to see what's changed, and if it's acceptable they would check it in. If a build is needed, a build can be performed on the files on disk that have the changes. In addition, if a user doesn't like what is seen they just Undo the changes in that list and it's back to the state prior to the merge branches. In a way, this sort of does act as a preview.

It looks like you're suggesting something be added in the middle of the wizard. Adding a mini-merge branches in the middle of the real merge branches could potentially add significantly to the time it takes to perform a merge branches if it's a large merge. Or, at least, I can't envision the way you want this to work.

I've logged a request to not have the moves, renames, and shares not commit automatically, but to place them in the pending changes with the other changes.
F: 16079

[CdrJameson]

I've logged a request to not have the moves, renames, and shares not commit automatically, but to place them in the pending changes with the other changes.
F: 16079

I've just realised that this is why none of my shares ever merge correctly!

Many of my changes are eliminating duplicated files from the repository and replacing them with shares.
This requires two operations: Delete the duplicated file and replace it with a share.

As the branch merge processes the 'share' before the 'delete', it fails (can't share on top of an existing file).
The 'delete' however ends up in the change set and removes the file, but with no share to replace it the build falls over until I put the shares back in by hand.

This would be solved if the share was postponed until the entire change was committed, as the operations would then happen in the right order.

[Beth]

Thank you for the update on your situation. I've added these details to the request to show what is happening.