Hi Konstantin, thanks a lot for your answer.
I've already found <sparse checkout> by myself and it seemed interesting. The fact you're mentioning it too is reassuring. However, as you seem to confirm, this doesn't avoid the burden of having the entire repo on the local machine. (I'm well aware of the DVCS nature of Git) That being said, having it once would be acceptable, it's having it multiple times that I would like to avoid. The multiple worktrees attached to a single repository seems to be the solution here. Thanks! Now I must just work out how this can be done from within VS without too much hassle. I've already spent quite some time reading "Pro Git" as you can imagine, but your direct links are valuable pointers nevertheless. Thank you for that. Concerning the merge idiom, maybe we've been doing it all wrong, but in TFS/TFVC, branches are hard top level structural objects and merges can be done on a single changeset level. We fix a bug on say branch A, then "merge" the changeset (and only that changeset) to branch B. This does indeed create "diagonal" ties between branches, but doesn't end either branch. Probably this "merging" of individual changesets is TFVC slang and the cherry-picking equivalent of Git. regards, Lars R. On Wed, Nov 24, 2021 at 7:22 PM Konstantin Khomoutov <kos...@bswap.ru> wrote: > On Wed, Nov 24, 2021 at 09:16:21AM -0800, Lars Ruoff wrote: > > [...] > > We use a minimalist branching workflow in that there is a main > development > > branch, then at regular intervals, we branch off what will be the > customer > > release versions. > > These different releases have to be maintained for several years each. > > Bug fixes may go to either branch and may then be merged into the others. > > This point "then be merged into the others" is a red flag for me but there > could be some terminological problem; I'll address it later. > > > Note that we are talking TFS/TFVC style "heavyweight" branches here. > [...] > > The Tests part isn't needed by every developer though. > > In TFS/TFVC, we have the common practice to "cloak" the Tests for people > > not concerned and "map" them to different parts of the file system for > > those who are. > [...] > > 1) > > It seems that the above size and layout may pose problems when using Git? > > Especially, we don't want people not using the Tests part to suffer any > > burden (disk space, checkin/out performance) when working locally. > > Is it possible? Should we structure our repository differently? > > Yes, it's possible, and no, it's not needed to restructure the repository: > Git has a feature called "sparse checkout" [1] which can be used to not > check out parts of the project layout which match a set of configured > patterns. (You can also search the 'net for "git sparse checkout" to read > informal intros to this topic.) > > Note that there may be some mismatches in terminologies between Git and > TVFS. > Since Git it a distributed version control system (a DVCS), each developer > has > its own local version of the repository. Usually an enterprise has a > central > "rendez-vouz", "blueprint" repository everyone sends their work to and > fetches > the work of others from, and for this reason local versions of such > repository > are typically called "clones". This basically means every developer will > have > those 10+ GiB of data on their filesystem. > Now "checking out" in Git has no relation to fetching data from some > repository, instead, it's an act of populating the so-called "work tree" - > a > directory on the file system attached to the local repository - with the > state > of a certain commit recorded in that repository. The developer then > modified > the files in the work tree and then records the changes, producing a new > commit. So, sparse checkout allows to omit certain path hierarchies when > populating the work tree, but the data which is omitted is still kept in > the > repository. > > > Also is it possible to map the Tests part to a different part of the > > filesystem? > > AFAIK, there is no direct support for that in Git but I think it can be > done > with some effort (that would possibly require setting up another local > repository which will borrow the objects from the original one (Git can do > that) and then use sparse checkout feature configured "inversely" to the > original repo - so that there Git ignores the source code files but checks > out > the test suite.) Probably there are simpler ways to do that but the obvious > question is: why not solve this using directory symbolic links? > > > 2) > > Concerning the branch layout. > > With TFS, developers were used to having several working copies (called > > workspaces in TFS), for working on different subjects and the different > > This one is easy as Git supports multiple worktrees attached to a single > repository [2]. > > Note that this has nothing to do with branch layout (may be this is another > terminological mismatch). > > > We'd prefer solutions that work well with Visual Studio. > > (VS does integrate git support natively in the IDE for common tasks) > > Configuring sparse checkout and several work trees are all stock Git > operations but I have no idea if the VS plugin for Git covers them. > Anyway, I think it's possible to occasionally resort to typing some > commands > in cmd.exe or provide the devs with scripts (or some crude GUI tool) to do > that. Also good 3rd-party Git front-ends exist which might have support for > this stuff; personally, I'd recommend to look at Git Extensions [3]. > > > OK, let me now address two points from your question here (so that they do > not > derail the flow of the answer). > > First, you could consider submodules [4] and split your monorepo into two > repositories - one with the source code and another one with tests. > Submodules is a way for one repository to "refer to" one or more other > repositories. A key property of this approach is that the "main" repository > (module) refers to particular commits in its submodules, and these > references > are maintained in a file which is committed in the main repository. This > way, > you still can have strict correlation between commits in the repository > containing the source code with the matching commits in the repository > containing the tests. > > Another possibility - as you appear to be a Windows-only shop - is to > explore > the possibility of using VFSForGit (ex GVFS) [6]. I did not use it > personally > so cannot really comment on its pros and cons, but ISTR it's used by > Microsoft > (who has developed it) for in-house work. > > Second, as I've said, the statement > > Bug fixes may go to either branch and may then be merged into the others. > sounds foreign to the ear of a Git user. > In Git, merging "binds" one or more lines of history together - creating a > special commit, from which all those lines will be "reachable" (can be > traversed from the merge commit all the way down), like this: > > -->A-->B-->C-\ > M-->... > -->X-->Y-->Z-/ > > Hence when you have several release branches - as you seem to do - it's > unnatural to use merging to bring the same change into multiple such > branches > because such merges would create bogus ties between the branch which > implements the original fix and the branch which recive the fix. > > In Git, it's more natural to use "cherry-picking" [5] to bring a series of > changes into multiple disjoint places. > > > To round up, I'd recommend to first read up on Git (the "Pro Git" book is a > good start, see [4]) then try to play with multiple approaches to > organizing > the repositories and the workflow, maybe ask further questions and then > settle > on which works best. > > 1. https://git-scm.com/docs/git-sparse-checkout > 2. https://git-scm.com/docs/git-worktree > 3. https://gitextensions.github.io/ > 4. https://git-scm.com/book/en/v2/Git-Tools-Submodules > 5. https://git-scm.com/docs/git-cherry-pick > 6. https://github.com/microsoft/VFSForGit > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Git for human beings" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/git-users/_BLyDQ1hB_w/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > git-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/git-users/20211124182212.mqvikcp7chu75ygt%40carbon > . > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CANWCJm%2Bp%3DssUcjS_SU51fT8Pw0dS8yf5YuM4dT7VGvjZ4Em4NQ%40mail.gmail.com.
