Item status is not cascading to parent levels

Issue #21 open
Eugene Baranov
created an issue

I think that if there was any changes then parent containers should be marked as changed as well -- it take a bit of time to find out what was changed in the solution of 10 project when they are all collapsed...

Comments (10)

  1. Sergey Antonov repo owner
    • changed status to open

    I allready fixed this in the trunk by allowing to run commit/revert commands from any file in solution explorer (if repository was modified).

    This fix will be included in the next version of the plugin.

    As for changing parent container glyph, I don't think that this is a good idea, because it will be too confusing.

  2. Eugene Baranov reporter

    Regarding parent container glyph -- what I'm suggesting is how it works in most extensions/plug-ins, including TortoiseHg, TortoiseSVN and AnkhSVN.

    And it makes sense, because, folder is just a special type of file consisting of other files. And as changing of some bytes in the file means that the file itself was changed, similarly changing of files within folder means that the folder was changed itself. So I'm additionally suggesting to put glyphs to folder as well (and treat Projects and Solutions as folders).

  3. Anonymous

    I'm used to the behavior Eugene has described. If I make a patch that enables the parent glyph changes as an option, will you consider merging it? I can be off by default if you'd like.

  4. Sergey Antonov repo owner

    Yes, I will consider to merge it.

    I think that if parent container for changed file is not changed itself it should use distinct glyph. There is one reserved custom glyph available, which can be used for that.

  5. Anonymous

    You did an amazing job integrating mercurial with Visual Studio, but this is the main feature I am missing. Part of it is also propagating the status to folders on the project and solution levels since I have complex solutions that contain all kinds of folders to group projects and group source files.

    Also, please allow people to select their own glyphs. Most people are used to SVN/CVS style icons so this lock business is not helping. I understand that you are limited in the number of glyphs you can add, so maybe at least let us pick which one maps to which status. I would prefer to have a check mark when it is checked in.

    I will look at the source and see what I am able to contribute.

    спасибо сергей

  6. MaXKilleR

    I have checked into this and came to the conclusion that the only way to do this with folders included is by making a visual studio Add-in (like VisualSVN did) and not a Scc plugin because the Scc provider does not support glyphs for folder nodes. I do not see any information about this being changed in VS2010 SDK.

    Keeping that in mind, you can still control the project glyph based on the files within it, which should narrow down the search of where the modified files are. I have done this for personal use, but in the end it is not a solution to the problem.

    I hope you consider rewriting this plugin as a normal Add-in, which will remove all the idiotic limits, such as a max of 4 custom glyphs and so on. I do not see why anyone would want to use Scc, it seems way too limiting and complicated to be a source control API layer.


  7. Sergey Antonov repo owner

    Even though, that MS SCC Package API have some limits (like 4 custom glyphs for solultion explorer tree), it is also an official SCC API supported by all project types and editors in Visual Studio. I mean, it asks for source controls status. provides notifications for file editing, adds only files, that should be controlled by source control, supports SCC bindings in solution and projects, etc...

    If you want to write an Add-on as source control provider, then you will have to handle all of above yourself.

    I don't have a time and resources for that and I think it is a wrong way to go.

  8. MaXKilleR

    I understand and I agree that it will take quite a lot of time. There is a reason why VisualSVN is a commercial product.

    I was thinking of making a synchronize explorer which will show you a tree hierarchy of any incoming and outgoing changes. I am an avid VS user, but I use eclipse for my current job and I love the team synchronize view, so I feel it will help a lot when it comes to sorting out all the changes. Let me know what you think of this.

    I know you wanted some help with this one man project, so I am trying to find the time to contribute.

  9. MaXKilleR

    Sorry to say this but I have decided to make my own Mercurial source control plug-in. There are just way too many things I would like to change, so I think it is better if I make my own.

    I already made some progress with the current issue, but it was most definitely a challenge to even find where to start from.

    I wish you good luck and hope to see what new things you have in store for us.

  10. Log in to comment