Keyword Feature Enhancement

[kmxsoft]

I'm not sure whether this is already available.

It would be useful if the history keyword had an option to limit the number of history records to report. At present it seems to be an all or nothing deal, but for most purposes only the most recent change(s) are needed.

[jclausius]

No that is not available. I'll add this as a feature request.

As a brute-force work around, at this time any unwanted expanded items would need to be trimmed from the file before it is committed back to the Vault server.

[kmxsoft]

No that is not available. I'll add this as a feature request.

As a brute-force work around, at this time any unwanted expanded items would need to be trimmed from the file before it is committed back to the Vault server.

Thanks Jeff.

I tend to submit in-progress work frequently, as in daily. With history enabled my historical comments can quickly become overwhelming in terms of quantity.

Perhaps there might be some scope for marking comments with a tag (or prefix) to enable/disable their inclusion in the history list.

[jclausius]

The feature request I added was to add some delineation that would put a limit / cap on the # of entries that could be found with KW (knocking off the bottom most entry once that limit is reached). There might be some difficulties as there are not necessarily delineation marks for stripping out old entries.

In any case, in your last post, I believe this suggestion is something new. Just to clarify, are you're asking for a checkbox option during the commit dialog to skip KW expansion during this commit?

[kmxsoft]

In any case, in your last post, I believe this suggestion is something new. Just to clarify, are you're asking for a checkbox option during the commit dialog to skip KW expansion during this commit?

Please ignore that last comment, I was spouting gibberish.

The ability to limit the number of historical comments would be very useful. I recall that was an option in another version control program I used some time ago. It's implementation is probably fairly simple - increment a counter for each historical comment posted and once a given limit was reached then stop posting historical comments. There doesn't need to be a complex algorithm.

Rather than add additional functionality, this counter could be applied to ALL historical record processing, with a default limit on the number of records processed set arbitrarily high. Maybe that arbitrary limit could be defined in the web control panel for the source code project rather than being scripted in the keywords?

[jclausius]

OK. I understand, and perhaps should have asked for more details in my earlier post.

What I had recorded was to keep the last "top" of N comments. So, for example, KW has some type of formatting that says, "N:3". You check in version 1, 2, and 3, and the history expansion occurs. On the 4th modification / commit, version 1's item is edited out (since it is jut plain text at this point in time), and version 4 expansion is physically added to the file... So, the expanded text is shown for version 4, 3, and 2.

Next, Version 5 is made, and now version 2 is physically deleted from the file, leaving 5, 4, and 3. There are difficulties in this scenario in finding / editing out past comments and when used in binary files, this is EXTREMELY dangerous, as it could end up in file corruption.

I've adjusted your feature request with the updated information you've provided.

I know this is not a per repository setting as you requested, but as a work around, after you reach the threshold within any given file, on the next edit of the file, by removing the keywords too, expansion would stop in that specific file.

[kmxsoft]

Adding this keyword expansion as a feature request doesn't appear to have had a response from the developers. That's fine, I've worked in development teams long enough to know such changes might not produce the desired result so I'm not moaning .

However, as presented earlier it would entail changes to the existing core keyword handling, and that could present some undesirable support options.

Would it perhaps be easier to add a new keyword, rather than change the existing? For example, adding a new keyword '$Log5' to report just the last 5 entries might be easier to implement than changing the existing '$Log' implementation requiring opening up and modifying that earlier definition, so from a support angle could provide the requested change without adding support concerns.

[Tonya]

Thank you for checking back in. We are currently working on Vault 11 but I can't confirm if this feature request will make the cut. I have added your additional thoughts to the feature request.

Thank you for the additional feedback.

Tonya