Hermann  Frami

Hermann Frami

1642223160

Virtual File System for Git: Enable Git at Enterprise Scale

VFS for Git

What is VFS for Git?

VFS stands for Virtual File System. VFS for Git virtualizes the file system beneath your Git repository so that Git and all tools see what appears to be a regular working directory, but VFS for Git only downloads objects as they are needed. VFS for Git also manages the files that Git will consider, to ensure that Git operations such as status, checkout, etc., can be as quick as possible because they will only consider the files that the user has accessed, not all files in the repository.

Note: for new deployments, we strongly recommend you consider Scalar instead of VFS for Git. By combining the lessons from operating VFS for Git at scale with new developments in Git, Scalar offers a clearer path forward for all large monorepos.

Installing VFS for Git

VFS for Git requires Windows 10 Anniversary Update (Windows 10 version 1607) or later.

To install, use winget to install the microsoft/git fork of Git and VFS for Git using:

winget install --id Microsoft.Git
winget install --id Microsoft.VFSforGit

You will need to continue using the microsoft/git version of Git, and it will notify you when new versions are available.

Building VFS for Git

If you'd like to build your own VFS for Git Windows installer:

  • Install Visual Studio 2017 Community Edition or higher (https://www.visualstudio.com/downloads/).
    • Include the following workloads:
      • .NET desktop development
      • Desktop development with C++
      • .NET Core cross-platform development
    • Include the following additional components:
      • .NET Core runtime
      • Windows 10 SDK (10.0.10240.0)
  • Install the .NET Core 2.1 SDK (https://www.microsoft.com/net/download/dotnet-core/2.1)
  • Install nuget.exe
  • Create a folder to clone into, e.g. C:\Repos\VFSForGit
  • Clone this repo into the src subfolder, e.g. C:\Repos\VFSForGit\src
  • Run \src\Scripts\BuildGVFSForWindows.bat
  • You can also build in Visual Studio by opening src\GVFS.sln (do not upgrade any projects) and building. However, the very first build will fail, and the second and subsequent builds will succeed. This is because the build requires a prebuild code generation step. For details, see the build script in the previous step.

You can also use Visual Studio 2019. There are a couple of options for getting all the dependencies.

  • You can install Visual Studio 2017 side by side with Visual Studio 2019, and make sure that you have all the dependencies from Visual Studio 2017 installed
  • Alternatively, if you only want to have Visual Studio 2019 installed, install the following extra dependencies:

Visual Studio 2019 will automatically prompt you to install these dependencies when you open the solution. The .vsconfig file that is present in the root of the repository specifies all required components except the Windows 10 SDK (10.0.10240.0) as this component is no longer shipped with VS2019 - you'll still need to install that separately.

The installer can now be found at C:\Repos\VFSForGit\BuildOutput\GVFS.Installer.Windows\bin\x64\[Debug|Release]\SetupGVFS.<version>.exe

Trying out VFS for Git

  • VFS for Git requires a Git service that supports the GVFS protocol. For example, you can create a repo in Azure DevOps, and push some contents to it. There are two constraints:
    • Your repo must not enable any clean/smudge filters
    • Your repo must have a .gitattributes file in the root that includes the line * -text
  • gvfs clone <URL of repo you just created>
    • Please choose the Clone with HTTPS option in the Clone Repository dialog in Azure Repos, not Clone with SSH.
  • cd <root>\src
  • Run Git commands as you normally would
  • gvfs unmount when done

Note on naming

This project was formerly known as GVFS (Git Virtual File System). You may occasionally see collateral, including code and protocol names, which refer to the previous name.

Author: Microsoft
Source Code: https://github.com/microsoft/VFSForGit 
License: MIT License

#git #microsoft #csharp 

What is GEEK

Buddha Community

Virtual File System for Git: Enable Git at Enterprise Scale
Hermann  Frami

Hermann Frami

1642223160

Virtual File System for Git: Enable Git at Enterprise Scale

VFS for Git

What is VFS for Git?

VFS stands for Virtual File System. VFS for Git virtualizes the file system beneath your Git repository so that Git and all tools see what appears to be a regular working directory, but VFS for Git only downloads objects as they are needed. VFS for Git also manages the files that Git will consider, to ensure that Git operations such as status, checkout, etc., can be as quick as possible because they will only consider the files that the user has accessed, not all files in the repository.

Note: for new deployments, we strongly recommend you consider Scalar instead of VFS for Git. By combining the lessons from operating VFS for Git at scale with new developments in Git, Scalar offers a clearer path forward for all large monorepos.

Installing VFS for Git

VFS for Git requires Windows 10 Anniversary Update (Windows 10 version 1607) or later.

To install, use winget to install the microsoft/git fork of Git and VFS for Git using:

winget install --id Microsoft.Git
winget install --id Microsoft.VFSforGit

You will need to continue using the microsoft/git version of Git, and it will notify you when new versions are available.

Building VFS for Git

If you'd like to build your own VFS for Git Windows installer:

  • Install Visual Studio 2017 Community Edition or higher (https://www.visualstudio.com/downloads/).
    • Include the following workloads:
      • .NET desktop development
      • Desktop development with C++
      • .NET Core cross-platform development
    • Include the following additional components:
      • .NET Core runtime
      • Windows 10 SDK (10.0.10240.0)
  • Install the .NET Core 2.1 SDK (https://www.microsoft.com/net/download/dotnet-core/2.1)
  • Install nuget.exe
  • Create a folder to clone into, e.g. C:\Repos\VFSForGit
  • Clone this repo into the src subfolder, e.g. C:\Repos\VFSForGit\src
  • Run \src\Scripts\BuildGVFSForWindows.bat
  • You can also build in Visual Studio by opening src\GVFS.sln (do not upgrade any projects) and building. However, the very first build will fail, and the second and subsequent builds will succeed. This is because the build requires a prebuild code generation step. For details, see the build script in the previous step.

You can also use Visual Studio 2019. There are a couple of options for getting all the dependencies.

  • You can install Visual Studio 2017 side by side with Visual Studio 2019, and make sure that you have all the dependencies from Visual Studio 2017 installed
  • Alternatively, if you only want to have Visual Studio 2019 installed, install the following extra dependencies:

Visual Studio 2019 will automatically prompt you to install these dependencies when you open the solution. The .vsconfig file that is present in the root of the repository specifies all required components except the Windows 10 SDK (10.0.10240.0) as this component is no longer shipped with VS2019 - you'll still need to install that separately.

The installer can now be found at C:\Repos\VFSForGit\BuildOutput\GVFS.Installer.Windows\bin\x64\[Debug|Release]\SetupGVFS.<version>.exe

Trying out VFS for Git

  • VFS for Git requires a Git service that supports the GVFS protocol. For example, you can create a repo in Azure DevOps, and push some contents to it. There are two constraints:
    • Your repo must not enable any clean/smudge filters
    • Your repo must have a .gitattributes file in the root that includes the line * -text
  • gvfs clone <URL of repo you just created>
    • Please choose the Clone with HTTPS option in the Clone Repository dialog in Azure Repos, not Clone with SSH.
  • cd <root>\src
  • Run Git commands as you normally would
  • gvfs unmount when done

Note on naming

This project was formerly known as GVFS (Git Virtual File System). You may occasionally see collateral, including code and protocol names, which refer to the previous name.

Author: Microsoft
Source Code: https://github.com/microsoft/VFSForGit 
License: MIT License

#git #microsoft #csharp 

Madyson  Reilly

Madyson Reilly

1604109000

Best Practices for Using Git

Git has become ubiquitous as the preferred version control system (VCS) used by developers. Using Git adds immense value especially for engineering teams where several developers work together since it becomes critical to have a system of integrating everyone’s code reliably.

But with every powerful tool, especially one that involves collaboration with others, it is better to establish conventions to follow lest we shoot ourselves in the foot.

At DeepSource, we’ve put together some guiding principles for our own team that make working with a VCS like Git easier. Here are 5 simple rules you can follow:

1. Make Clean, Single-Purpose Commits

Oftentimes programmers working on something get sidetracked into doing too many things when working on one particular thing — like when you are trying to fix one particular bug and you spot another one, and you can’t resist the urge to fix that as well. And another one. Soon, it snowballs and you end up with so many changes all going together in one commit.

This is problematic, and it is better to keep commits as small and focused as possible for many reasons, including:

  • It makes it easier for other people in the team to look at your change, making code reviews more efficient.
  • If the commit has to be rolled back completely, it’s far easier to do so.
  • It’s straightforward to track these changes with your ticketing system.

Additionally, it helps you mentally parse changes you’ve made using git log.

#open source #git #git basics #git tools #git best practices #git tutorials #git commit

Ruth  Nabimanya

Ruth Nabimanya

1620633584

System Databases in SQL Server

Introduction

In SSMS, we many of may noticed System Databases under the Database Folder. But how many of us knows its purpose?. In this article lets discuss about the System Databases in SQL Server.

System Database

Fig. 1 System Databases

There are five system databases, these databases are created while installing SQL Server.

  • Master
  • Model
  • MSDB
  • Tempdb
  • Resource
Master
  • This database contains all the System level Information in SQL Server. The Information in form of Meta data.
  • Because of this master database, we are able to access the SQL Server (On premise SQL Server)
Model
  • This database is used as a template for new databases.
  • Whenever a new database is created, initially a copy of model database is what created as new database.
MSDB
  • This database is where a service called SQL Server Agent stores its data.
  • SQL server Agent is in charge of automation, which includes entities such as jobs, schedules, and alerts.
TempDB
  • The Tempdb is where SQL Server stores temporary data such as work tables, sort space, row versioning information and etc.
  • User can create their own version of temporary tables and those are stored in Tempdb.
  • But this database is destroyed and recreated every time when we restart the instance of SQL Server.
Resource
  • The resource database is a hidden, read only database that holds the definitions of all system objects.
  • When we query system object in a database, they appear to reside in the sys schema of the local database, but in actually their definitions reside in the resource db.

#sql server #master system database #model system database #msdb system database #sql server system databases #ssms #system database #system databases in sql server #tempdb system database

7 Best Practices in GIT for Your Code Quality

There is no doubt that Git plays a significant role in software development. It allows developers to work on the same code base at the same time. Still, developers struggle for code quality. Why? They fail to follow git best practices. In this post, I will explain seven core best practices of Git and a Bonus Section.

1. Atomic Commit

Committing something to Git means that you have changed your code and want to save these changes as a new trusted version.

Version control systems will not limit you in how you commit your code.

  • You can commit 1000 changes in one single commit.
  • Commit all the dll and other dependencies
  • Or you can check in broken code to your repository.

But is it good? Not quite.

Because you are compromising code quality, and it will take more time to review codeSo overall, team productivity will be reduced. The best practice is to make an atomic commit.

When you do an atomic commit, you’re committing only one change. It might be across multiple files, but it’s one single change.

2. Clarity About What You Can (& Can’t) Commit

Many developers make some changes, then commit, then push. And I have seen many repositories with unwanted files like dll, pdf, etc.

You can ask two questions to yourself, before check-in your code into the repository

  1. Are you suppose to check-in all these files?
  2. Are they part of your source code?

You can simply use the .gitignore file to avoid unwanted files in the repository. If you are working on more then one repo, it’s easy to use a global .gitignore file (without adding or pushing). And .gitignore file adds clarity and helps you to keep your code clean. What you can commit, and it will automatically ignore the unwanted files like autogenerated files like .dll and .class, etc.

#git basics #git command #git ignore #git best practices #git tutorial for beginners #git tutorials

Loma  Baumbach

Loma Baumbach

1601157360

Mirroring Git Changes From One Server to Another Server

Introduction

Hello all, nowadays most of the development teams using GIT version control, some of you may have a requirement of mirroring your team’s git changes from one server to another Git server. This article will help you to achieve the Git mirroring between one server to another server.

Business Case

I got one assignment wherein there will be 2 Git Servers, development will happen in one Git server and the changes should be synchronized to another Git server at regular intervals. But in my case, the complexity is both the servers are in different restricted network. So I have done the small experiment and it worked. And I am sharing the steps to you all in this article.

The Experiment Performed Using Below 2 GIT Servers

Main GIT Server: Let’s take our main git server is located in our office and can be accessed only in-office network.

**Mirror GIT Server: **The mirror server is located at the vendor/client-side, which can be accessible in a normal internet connection but not with our office network. Since the office proxy will block the outside URL’s.

#devops #git #git and github #git best practices #git cloning #git server