Merge Branches tool to limit versions

[robe070]

Hi,

I would like to request that the merge branches tool is enhanced so that the number of versions listed is limited in the first instance and more can be requested if required.

We currently have 5000 versions in our origin folder (Trunk). This will only continue to grow. Our policy is to make changes to the Trunk so that future releases will contain the change. We then merge it into other branches for Service Packs. From a performance point of view, making the change in the branch and then merging to the Trunk is much quicker. But in general thats more risky for us so we don't do it. Currently its taking about 2 minutes on fast machines. And we are doing many merges each day. Not that that is common - its just the stage we are at in the development life cycle.

Also every merge we are doing currently is in the top 10, if not the very top item.

I would suggest something like a 'More' button that might get the next 100 versions. And also an 'All' button. Maybe the 100 could be configurable - as PCs get faster it would be able to increase. For our purposes I would expect less than 1 in 1000 to be outside the top 100 versions.

Also on merge tool and performance, could you make it optional to check the Target folder for changes? If you know what you are doing its a waste of time (10 minutes on fast PCs sometimes). For our team its ALWAYS clean or displays irrelevant changes.

And another one whilst I'm thinking about it - the default comment produced contains all the information we need, but the most important information, or at least the information that is useful in say a history summary, is the original comment. Having "Merge Branches: Origin=$/VL/Trunk/work " in History is not informative. Could the target comment be configurable or even hard code the origin's comment as the first text in the target comment? (Yes I know I can change it, but developers are lazy!)

regards

Rob Goodridge

[GregM]

I asked about that here:

http://support.sourcegear.com/viewtopic ... 25&p=11618

A date range like on the history query dialog would be helpful too. We very rarely merge something that wasn't committed today, and then it's generally at most a month in the past. I think I've requested that before, but I couldn't find it in a search, so it may have been via email.

[Beth]

I've got everything logged and voted on. Thanks for the feedback.

F: 14157, 14671, 14672

[lynnroth]

Please add my vote to this. In our environment merging takes so long that we tend to break our best practices and code on the branch rather than the trunk, which causes issues if the change doesn't get merged back to trunk. I see this as the biggest issue we have with Fortress/Vault.

Thanks

[Beth]

I've added your votes. Thank you for the feedback.

[lynnroth]

This issue continues to slow us down and cause problems.

Is this on the schedule for being implemented any time soon?

[robe070]

From our perspective version 5 had few useful enhancements, and the main one - ShelveSets - has major useability issues. I presume that ShelveSets were very difficult to implement and thus sucked too much resource.

Also the suggestions in this thread would be extremely useful for ANYONE using the merge tool and would surely be very easy to implement. Why couldn't the resource be found?

It looks from the outside that fewer resources are being applied to Vault. We are very concerned at this turn of events.

And as for actually providing a proper merge tool using 3-way merge (suggestions on this in a prior thread) seems highly unlikely, even though SourceGear have suggested the Merge Tool needs work on it.

Yes, we are very concerned.

[jclausius]

Rob,

Vault and Fortress features / fixes are usually decided by user feedback, tech support requests and features nagging any within the dev team. Using that criteria, the feature set within Vault 5/Fortress2 focused on Shelving, fixes to support Visual Studio 2010 integration, a new WebDAV client, optimizing for CC.NET, VSS Handoff, and a Complete re-design for the Web interface (for Fortress). There were other fixes, but these items took the bulk of the time that went into the release.

Now, in regards to the request in general, there are good ideas here and would help streamline the merge process. I'll bump them in priority, and discuss this with the dev team for an upcoming release maintenance or full feature release of Vault.

[lynnroth]

Jeff,
Thanks for the update and for taking our issues seriously. I look forward to seeing what you come up with. If there are any questions about our process, feel free to let me know.

[jclausius]

Lynn,

Between Rob, GregM, and yourself we have a nice request list which would help out when Merging. Things are busy right now for the dev team's current task list, but I'll update this thread once we've sat down and talked about what needs to be done.

Thanks again.

[robe070]

Thanks Jeff for that clear response and indication of applying some resource soon to make the Merge Tool enhancements. If you would like a beta customer my hand is up!

[GregM]

I really hope this will be done soon. It's been more than 5 years since I first brought up this issue and it's really making things difficult for us, especially when it never returns and we have to exit and start over.

http://support.sourcegear.com/viewtopic ... lit=+merge

At that time Eric was talking about a merge branches rewrite. Did anything ever happen with that?

[jclausius]

Greg,

We went down that path a couple different attempts, and all failed to produce anything of substance. I have this on the to-do list. There won't be anything tomorrow, and we're currently finishing other dev tasks - VS 2010 is challenging us right now (considering things worked on the VS 2010 beta, but do not work now).

Thanks.

[GregM]

Thanks for the update, and good luck with VS2010.

[lynnroth]

Jeff, is there any chance this feature is going to make it into Vault 6? Or preferably sometime in v5?

This issue really causes us pain and in our usage is the worst thing about Vault. The new features listed for 6 on the blog look great, but I would take a fix for this over any of them right now.