1. Sergey Antonov
  2. HgSccPackage
Issue #22 open

Support for few repositories in the same solution

Anonymous created an issue

Solution consists of few projects from different repositories. HgSccPackage can't correctly deal with such situation. Only one repository is recognized and being dealt with.

The problem is commonly spread and a lot of developers teams use a number of repositories instead of subreps (because it's much easier to push into central repo).

Support for multiple perositories will be highly appreciated. :)

Comments (13)

  1. Sergey Antonov repo owner

    So, if I understand correctly it should work as folows:

    1. On solution level all commands are disabled (except clone)
    2. On the project level the commands works only with repository to which that project belong.
    3. If you add new project to such solution, then 'Add to source control' command should create new repository for that project or use existing repository, if it exists on that location.

    Right ?

  2. shadowbroker

    Well, i've just got a quick overview of your code. I think that it could be implemented in the following way:

    1. make a dictionary with pairs <IVsHierarchy,SccProviderStorage> within SccProviderService, this will allow to define root directory for every project and for the solution treated as a file.
    2. it's vital in case of supporting multiple working directories to have a way to quickly find out in which project (IVsHierarchy) file with given name resides (constant enumeration through solution and projects or some kind of cached mapping in SccProviderService - it's up to you to decide ).
    3. during execution of some commands prev. target is easy to achieve, you know selected nodes (VSSELECTEDITEM) and instantly theirs IVsHierarchy.
    4. Here comes next, some commands should be restricted in their QueryStatus_* to work on selected set of files belonging to one project (or may be to the same working root).
    5. working with solution should be treated as working with root directory which contains the .sln itself.
    6. And yes, 'Add to source control' should work as you offered.

    And when (i hope it will happen) all above come true it will be time to think about extending GUI and adding few new commands to ease working with few roots - for example group fetching, pulling or pushing, updating [EDITED: how could i forget about commiting]. At least it could be achieved root by root - window by window even without modifying any controls right now. The greater good :) is giving user experience as if he is working with one repository even if it's not quite true and at the same time provide flexible control over multiple repositories involved in developing process.

    This is how i see this great feature

    P.S.: And of course dont take too seriously my tech details of implementation - again, it's all up to you and i've made really QUICK code overview. P.S.S: Anyway, you've already made a great job. Keep it coming!! :) Даешь классную интеграцию Mercurial с VS - VisualHG по сравнению с твоим проектом дешево смотрится, да и вообще поделка посредственная опять же на скорый взгляд, но вот недавно внедренной поддержкой мультирутовости они подкупают. Если у тебя это будет - всех порвешь я думаю ))))

  3. Sergey Antonov repo owner
    • changed status to open

    This issue is fixed in trunk and the fix will be included in v1.3.

    But, group operations on multiple repositories at once are not yet implemented. I need more time to design this feature and make it convenient to use.

  4. Anonymous

    Hi zzsergant,

    Have you had time to design the feature of group operations on multiple repositories (sub-repositories)? It would be really useful to have HgSccPackage track changes made to sub-repositories inside a solution so that theses changes appear in the Commit window. I understand that you don't necessarily have time and resources to work on your plugin, but it is by far the best HG plugin for VS I have used so far.

    Do you sometimes accept merges for your plugin if someone would make such a modification?

    Thank you and good work!

  5. Anonymous

    It is hard to work on a project alone. Currently I'm quite busy and don't have much time to work on the project. I will have more time after new year.

    Such complex features requires a good understanding and also a discussion with someone about how the feature should look and work. And since I do not use multiple repositories in one solution a lot myself I have not enough time and motivation to work on group operations.

    Also, there are two types of sub-repositories:

    1. Multiple repositories in one solution without nesting
    2. Mercurial subrepos, where one repository is nested in the other

    The 1st is allready implemented in v1.3, but without group operations. The 2nd is not implemented, but I have a patch from someone who added a partial support for subrepos and I just haven't applied it yet.

    As for patches, yes, I'm open for contribution. You can fork a project, work on some feature and then I can integrate it into the trunk.

    There is a wiki page which describes how to start working on a project for developers: https://bitbucket.org/zzsergant/hgsccpackage/wiki/Development

  6. Anonymous

    Thank you for a prompt reply!

    I was indeed referring to the second type, subrepos. I will then wait for your integration of the patch for subrepos support in HgSccPackage.

    I am evaluating switching to mercurial for the company I work for and so far I really like HgSccPackage. In my opinion, it looks much better that VisualHG, who relies on the GUI of TortoiseHG. Also, the integration of HgSccPackage into Visual Studio feels a lot tighter and more similar to other source control plugins. The only thing missing is subrepos support ;)

    Keep up the good work and looking for further enhancements to HgSccPackage!

  7. Sergey Antonov repo owner

    I've merged the initial subrepo support patch into the trunk.

    In fact this patch was pending in my TODO queue for a few months allready. I just thought that subrepo support was not that mature yet in mercurial to support it in the plugin. But since more and more ppl request it I decided to move it on top of my queue :)

    Anyway, I still don't know all corner cases of subrepo usage. Will look into it after new year.

  8. Anonymous

    Hi,

    I'm using HgSccPackage v1.8.1 with Mercurial 1.8.4 and have an issue with subrepos in VS2010. If I have 2 projects in the same solution, say 'Company.Common.Tools' and 'Company.Common.Tools.Configuration', each having its own repository, HgSccPackage sees the first project ('Company.Common.Tools') as being under source control, but the second one is seen as NOT being under source control. I think the problem is that the second project has the name of the first project in it's name ('Company.Common.Tools') because if I add another project with a different name, say 'Company.Model', it works fine.

    Thank you.

  9. Sergey Antonov repo owner

    I've fixed the bug with path comparison for subrepos. The quick fix is attached to this issue and will be included in the next version.

    You will need to uninstall the previous version of HgSccPackage manually, because I did not changed a package version.

    BitBucket do not send a notifications from the posts made by anonymous, so I was unaware of your comment.

  10. Anonymous

    Me again.

    Say I commit changes to a subrepo. HgScc does not detect the change of the subrepo's state so I cannot commit the new state of the subrepo in to parent repo.

    Keep up the good work!

  11. Log in to comment