如何使用Rubberduck管理本地git存储库 [英] How to manage a local git repository using Rubberduck

问题描述

我将 Rubberduck （版本2.0.13）与本地git存储库结合使用，以便对我的版本进行控制VBA项目。

目前，我需要在每次使用 Manage - > gtk启动Rubberduck时重新打开存储库。在源代码控制窗口中打开现有的存储库。

是否有更好的方式来处理本地存储库，例如可以用Rubberduck保存这个设置吗？我不想使用在线存储库，所以我认为Unsynced提交选项卡与我无关。 解决方案

这开始作为一个评论，但太长了...所以我想我会做一个令人失望的答案，而不是。

我个人不做很多VBA（最近无论如何），所以我不能说我主动使用了Rubberduck的源代码控制功能，并且我没有真正为那个部分贡献很多，但我知道似乎可以使用它的用户 - 与本地和远程存储库：这些用户可以给我一个比我使用它更好的答案。

有是相当多的开放涉及源代码管理功能的问题，甚至 a 点roject 致力于稳定它。基本上它是按原样提供的，比如比没有更好。

这个想法是，它应该选取 ProjectId （我们目前存储在启用写入的 VBProject.HelpFile 没有人使用过的属性 - 你想混淆了Rubberduck的问题，你只是改变了这个值），在我们解析它之后，所以我们确定项目在查找时具有一个ID ％appdata％\Rubberduck\SourceControl.rubberduck 文件来查看该项目ID是否与已知存储库关联 - 如果是这种情况，那么我们将打开该存储库并更新SC面板。

配置文件如下所示：

 <？xml version =1.0encoding =utf-8？> 
<配置> 
< SourceControlSettings> 
< UserName /> 
< EmailAddress /> 
< DefaultRepositoryLocation /> 
< Repositories> 
< Repository> 
< Id> 86689642< / Id> 
< LocalLocation> C：\Dev\VBA\VBTools< / LocalLocation> 
< RemoteLocation /> 
< / Repository> 
< / Repositories> 
< CommandPromptLocation> cmd.exe< / CommandPromptLocation> 
< / SourceControlSettings> 
< / Configuration> 
  

我们 存储信息 - 存储库< Id> 应完全用于此目的，因此它可以正常工作但不可靠，或者它正在创建问题并被禁用。

但是您是正确的：每次手动打开工作存储库都不是理想的UX。是否有遥控器不应该有所作为，当你有遥控器时，你仍然需要一个本地拷贝。

我记得有一次它有人辩论无论我们是否应该让用户浏览存储库位置，还是仅从配置文件中列出已知存储库 - 已决定让用户浏览并打开任何已知的或未知的git存储库，都会使其更容易和更灵活，特别是当Rubberduck尚未知道存储库时;如果您有想法或功能请求，请随时在GitHub上打开问题（或只是为了报告错误）。

I'm using Rubberduck (Version 2.0.13) in combination with a local git repository for version control of my VBA project.

Currently, I need to re-open the repository every time I start Rubberduck using Manage -> Open Existing Repository in the Source Control Window.

Is there a better way to handle the local repository, e.g. can Rubberduck save this setting? I don't want to use an online repository, so I think the "Unsynced commits" tab is irrelevant for me.

解决方案

This started as a comment, but got too long... so I figured I'd make a disappointing answer instead.

I don't personally do much VBA (lately anyway) so I can't say I actively use Rubberduck's source control feature, and I haven't really contributed much to that part, but I know users that seem to manage to use it - with both local and remote repositories: these users can probably give you a better answer than I can as far as using it goes.

There are quite a number of open issues involving the source control feature, even a project dedicated to stabilizing it. Basically it's provided "as-is", as in "better than nothing".

The idea is that it's supposed to pick up the ProjectId (which we're currently storing in the write-enabled VBProject.HelpFile no-one-ever-uses-that property - you want to confuse the heck out of Rubberduck you just change that value) of the active project, after we've parsed it, so we're sure the project has an ID when we look in the %appdata%\Rubberduck\SourceControl.rubberduck file to see if that project ID is associated with a known repository - and if that's the case, then we'd open that repository and update the SC panel.

The configuration file looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Configuration>
  <SourceControlSettings>
    <UserName />
    <EmailAddress />
    <DefaultRepositoryLocation />
    <Repositories>
      <Repository>
        <Id>86689642</Id>
        <LocalLocation>C:\Dev\VBA\VBTools</LocalLocation>
        <RemoteLocation />
      </Repository>
    </Repositories>
    <CommandPromptLocation>cmd.exe</CommandPromptLocation>
  </SourceControlSettings>
</Configuration>

We are storing the information - the repository <Id> should be used exactly for this, so either it's working but not reliably, or it was creating problems and was disabled.

But you are correct: having to manually open the working repository every time isn't an ideal UX. Whether there's a remote or not shouldn't make a difference, you still need to have a local copy when you have a remote.

I remember at one point it was debated whether we should let the user browse for repository location, or just list the known repositories from the configuration file - it was decided that letting the user browse and open any git repository known to Rubberduck or not, would make it much easier and flexible, especially when no repository is known to Rubberduck yet; feel free to open an issue on GitHub if you have ideas or feature requests (or just to report a bug).

这篇关于如何使用Rubberduck管理本地git存储库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！