Is it time to split the Repo?

[AdamSpeight2008]

I think it would soon be a good time to separate the different concerns out into their own Repos. The Roslyn Team would still own these repos, just like they do for this one.

Looking at the structure of src, I see at least 4 . Roslyn, Compilers, IDE, Interactive. This permits development at different cadences.

Roslyn This repo is to build the entire roslyn infrastructure

dotnet/roslyn
  + build
  + Sample

Compiler This repo is build and test the compiler infrastructure only, each language having it's own repo.

dotnet/roslyn/compiler
  / CSharp
  / VisualBasic
  / Common+Shared

These repos would be suitable target from any language specific documentation. Eg The grammar. Especially useful if you want to compare different versions of the language.

IDE This one is repo is to build and test the IDE / Visual Studio based aspects of Roslyn

dotnet/roslyn/IDE+VisualStudio
  + VisualStudio
    + EditorFeatures

Interactive This repo is to build and test the aspects of the interactive features.

dotnet/roslyn/Interactive+Scripting
  + Interactive
    + InteractiveWindow
  + Scripting

Plus a possible fifth Analysers+Diagnostics

Issues and Pull-Request target a specific aspect of the project. Allow us to subscribe to a specific aspect of the project, not to just one containing all of the issues.

For example language changes can be discussed and debated within dotnet/roslyn/compiler Changes specific to own language in;- dotnet/roslyn/compiler/CSharp and dotnet/roslyn/compiler/VisualBasic respectively.

It would allow team member and contributors to testing and trying new features or fixing bugs. To have quicker load time for the project, build, test times. As they not having build the entire Roslyn infrastructure each time. If someone breaks their aspect of the build it has little affect on other aspects. It would affect the repos above us if they pull the latest sources directly. Maybe they shoulf only reference specific package provided via a nuget service.

Forked branches would smaller and thus subsequent merges. Rebasing should also be simpler.

The initial setup and changes to the solutions and project would be a big cost, but I believe it would payoff in the long run.

[jakesays-old]

It is not time.

[AdamSpeight2008]

@jakesays I'm talking after the official release of VS2015.

[jakesays-old]

Me too. The repo is working well, especially for those of us who pull bits from several areas (compiler, ide, etc)

[AdamSpeight2008]

For that don't we having pull in changes to ain't related specific our area, which possible merge conflict that we have go fix. It is possible for those "sub-repos" to be pull / reference by your repo?

[Suchiman]

It would allow team member and contributors to testing and trying new features or fixing bugs.

I don't see how splitting improves that.

To have quicker load time for the project, build, test times.

You don't need to split repos for that and splitting solutions has it's own problems.

As they not having build the entire Roslyn infrastructure each time.

There's incremental build, you usually don't scrap the repo if you change one thing.

If someone breaks their aspect of the build it has little affect on other aspects.

Code that doesn't compiles is usually not checked in. If you are just testing one aspect and others are not working correctly, you don't touch them, do you? So it doesn't matter.

Forked branches would smaller and thus subsequent merges. Rebasing should also be simpler.

Smaller yes but since you are only working in your aspect you won't create conflicts in others so it doesn't affect rebase and so on.

The initial setup and changes to the solutions and project would be a big cost, but I believe it would payoff in the long run.

Big costs but i don't think it pays off

[AdamSpeight2008]

@Suchiman

There's incremental build, you usually don't scrap the repo if you change one thing.

I'm not saying abandoning this repo, I'm say it need restructuring into sub-repos. This repo would then be tailored more focused around building and test the entire infrastructure. Say for a release.

It would allow team member and contributors to testing and trying new features or fixing bugs.

I don't see how splitting improves that.

It would improve things as repo would be tailor to build and test, that specific area. Let's say someone is interest in just the C# compiler. Why should they have clone all on Roslyn? Why can't they clone just the C# compiler part of Roslyn?

There's incremental build, you usually don't scrap the repo if you change one thing.

Then why does the current build instructions, builds and tests the entire infrastructure. Why can't there be specific build and tests instructions for building and testing each aspect?

Code that doesn't compiles is usually not checked in. If you are just testing one aspect and others are not working correctly, you don't touch them, do you? So it doesn't matter.

Is does matter cause I can't build and test my aspect do the someone else.

Currently Cloning the repo and build doesn't work. Look at the recently load of issue related to build. Also look at the pull request not building. Presumable they built on their local machines, before submitting.

[Suchiman]

Code that doesn't compiles is usually not checked in. If you are just testing one aspect and others are not working correctly, you don't touch them, do you? So it doesn't matter.

Is does matter cause I can't build and test my aspect do the someone else.

with not working correctly i meant building but bugged.

Why can't there be specific build and tests instructions for building and testing each aspect?

because if you change one aspect you might break another aspect and you won't know until it somehow finds back together.

[AdamSpeight2008]

@Suchiman Want an examples of being screwed by others (see #3758, #1424, #1140, #933)

[Suchiman]

Interestingly they are all CodeFormatter runs, something that affects everything (all "aspects" at the same time) in the case of the first one and is limited to one aspect in other tickets. Major code formatter runs which cause huge deltas shouldn't run often / ever again if people obey the rules once the repo is on track. Also i don't see how they would've been less impactful if being run on seperate repos, you'll have to deal with code being altered concurrently and on a large repository it's even more unlikely to hit a conflict on the same file if not run by an automatic tool. It sounds like you rather like to have a warning on others committing changes that affects code you are working on.

Fact is, changes that need to be done concurrently will be done concurrently over the whole repo and changes that are local stay local, wether you are working in that area or not.

If i change file a in the big solution while you work on file b, nothing will happen to you. If i change file a while you are working on file a, you will have to merge, independently from wether it's a in a big or many small repos.

If you can't build a project anymore, that project won't build, independently from wether it's in the same repo or not. You can always set projects to don't build in the configuration manager if their build is broken to unblock the solution build. Having seperate repos won't help you, if the project that is broken in your dependency tree, you're screwed, wether they in seperate repos or not.

Seperating the projects would introduce a permanent new world of fun where you now have to categorize bugs wether they only happen when the repos are out of sync (using too new version of the compiler in a older ide repo), making discoverability harder and while nugeting would be possible, you are no longer able to easily build a complete build.

Using git techniques like submodule or subtree is another world of pain.

[jaredpar]

@AdamSpeight2008 Keeping our coding style consistent over the long haul is a goal we are very much committed to. The occasional runs of the code formatter are not screwing people, it's simply delivering on this goal.

Breaking up the repo into multiple sections wouldn't have any effect on the code formatter. The tool would still be run on any Roslyn controlled repo and hence the effects would be the same.

Now the intent is to run the tool more frequently (weekly ideally) to keep the diffs smaller. But RTM shipping tasks took priority here and we wanted to keep code churn low hence we held off on this for a bit. That time has passed now for the 'master' branch hence we are picking this up again.

[gafter]

Closing, as we have no intent to do this.