Split framework and console/engine into separate projects #1598
Comments
CharliePoole
changed the title
|
@nunit/core-team @nunit/contributors I've done a trial split to see what was involved and how well it worked. The results are mixed. I was able to remove both the working directory files and the history for framework using We also need to decide how many repos we want to have after this is done:
One thing that I realized in doing the trial split is that it's actually easier to split the extensions out first. I originally thought it didn't matter, but it turned out that I would have to do some work in the extensions for both splits unless I remove them first. So that's my next priority. There is a lot of dependency of different test projects on mock-assembly, which is built as a part of the framework build but used by engine, console and extension tests! Should we split that out into a repository? So, summarizing the decisions we need to make:
NOTE: Starting fresh is what I have done for the "minor" splits like teamcity extension.
Please think about this and let me have your opinions. I already posed some of these questions once, at the start of this issue and nobody has commented as yet. Your contribution of ideas is just as important to this project as your code! Since I'll focus next on splitting out the extensions, we have a bit of time to discuss these items, but not a lot! Charlie |
|
I think keeping history is important if at all possible. I often look through the history (perhaps in other projects more than here) in an attempt to track down the reason for code which looks a little odd. I'd go with filter-branch - splitting the history with where the files are going feels like the tidiest soution to me. |
|
That's the approach that makes sense to me if I can pull it off. There's the rub! As for tags, one issue I see is that you can't pull down a tag and necessarily build it after we remove stuff from the history. That may not be a problem if we all agree that's OK. Maybe I should create the new repos but keep the old one around for a release. |
|
A serious consideration with GitHub is what happens to the issues and pull requests? They appear to be sequential and linked to the local repo. It seems they aren't automatically copied across when you clone a repo. That's what happened with nunit-tdnet-adaptor, and links to old issues now link to new issues on the cloned repo. 😞 I don't know if its possible to properly clone a GitHub repo, along with all of its issues and pull requests. Something to investigate anyway! |
|
@jcansdale I planned on moving all relevant issues using ZenHub. That's what we have done in other cases. Are you saying that there were old nunit issues that became adapter issues? That shouldn't happen, since any nunit issue is supposed to be fixed for all users, not just those using the adapter. In my experience as a wandering coach, I've noticed that developers are sometimes willing to spend weeks creating an automatic process to do something that can be done manually in a matter of hours. That's why I always consider the manual option. Since ZenHub allows us to do this by clicking twice, there would need to be a heck of a lot of them before I would want to worry about automating it further. |
No. There were issues when the adapter when it was hosted at github/jcansdale. When these are referenced in the commit comments, they point at new issues in the new repo location. I think pull requests are implemented as a special kind of issue. We'll need to copy over all of the issues and pull-requests and make sure they have the same IDs in the copied repo. Does that make sense? |
|
Got it! Not sure how you can make issues and requests have the same id without a bunch of work, though. How about just pointing to the initial issue for tracking purposes? |
Unless there is a straightforward way to amend the commit comments, copying in the original issue description probably makes sense. It's not really a huge deal, just unfortunate and a learning experience. It looks like the NUnit repo has 1000 odd issues and 600+ pull requests! I wonder if there is a way to completely clone a repo along with its issues and requests? |
|
Actually, I think the existence of old PRs and issues is a reason to keep the original NUnit repo - probably renamed. That would leave "only" a few hundred issues and a small handful of PRs to transfer. |
|
I guess another possibility would be to keep nunit/nunit as a central repo for general NUnit issues (I believe this is what the xUnit folks do). When console and engine are split into separate repos, any comments with local issue/request links (i.e. |
|
"keep nunit/nunit as a central repo for general NUnit issues" What do @nunit/core-team and @nunit/contributors think about this? Is this contrary to the notion of separate teams and release schedules? or is it better for users who may not know where to put an issue? |
|
I was leaning towards a central repository for issues for all projects, but I have gone off the idea now for the following reasons, 1 - Different projects have their own milestones and release dates Why don't we keep the main NUnit repo as the framework repo rather than spinning a new repo off for it. We can rename it to NUnit.Framework if people prefer, but we shouldn't truncate history in this repo so that we have the full history. |
|
I like Rob's idea, which is a hybrid of my listed options. I'll restate this to make sure we are on the same page:
@rprouse What's your take on having separate engine and console repos rather than just the one. |
|
@CharliePoole exactly what I was thinking. Basically we are just moving the engine/console back to another repo like it originally was. As per separate engine/console repos, I think that is overkill don't you? I am also reticent to create a mockassembly repo since it is only one class. |
|
Do we worry about legacy issues / pull requests in the "other" repo(s)? My On 31 July 2016 at 23:15, Rob Prouse notifications@github.com wrote:
|
|
@jcansdale Could you spell out a hypothetical link situation such as you are concerned about? I'm not quite sure I get it. :-) @rprouse A full breakdown with engine and console in separate repos makes sense in some ways. But I would only advocate doing it now rather than later if we were sure we wanted it eventually. It can wait. MockAssembly is small enough to copy, so that 's what I'll do. |
Yes, take for example the following commit comment: If we split part of the repo off into a new repo, these links will now point at issues/requests in the new repo. As issues and pull-requests are added, links from old commit comments will point at these new issues. Here is a concrete example. Take the following commit: There is a link to pull-request |
|
Ah... I see. You said "commit comments" but I was thinking of comments on the PR or issue, which is a different matter. PR and issue comments with links are solved by Rob's suggestion that we don't move them. Commits obviously have to be moved. I'll try to think about a way to resolve this. We don't generally put links into commit comments, but github does it on merging PRs. If there is a relatively small number of them (say, < 100) then it's reasonable to just edit them all. More than that, I'd say no. |
|
Considering the issues that @jcansdale brings up, would we be better to...
If we did this, there would be no ambiguity. New history would be added, obviously, as we worked in the new repos. After a certain amount of time, there would probably be little use of the older history anyway. This is what i have done with the small repos like NUnit.System.Linq and teamcity-event-listener. Should we do it with the console/engine repo as well? |
|
Maybe it is just me, but I find looking at history for deleted files a I also think we should keep all history in the nunit repo. On Aug 1, 2016 8:55 PM, "CharliePoole" notifications@github.com wrote:
|
|
@rprouse I guess it's possible to truncate history, but it's not anything I've looked at doing. For each repo, there are three possibilities I see...
For the NUnit repo, which will become nunit framework, we have decided on option 1 I think. For the engine/console repo I was originally thinking of doing 2, but I just suggested 3. I think you are suggesting 1... correct? For the new extension repos, I would do 3, just to keep it simple. That's what I already did with teamcity. |
|
I think we need a home for the old pull-requests and issues. Keeping that in nunit/nunit makes sense. If it was possible to run a regex on commit comments after doing a filter-branch, we could automatically replace all |
|
I was suggesting 1 for the nunit repo and 2 for the console/engine repo but On 2 August 2016 at 07:37, Jamie Cansdale notifications@github.com wrote:
Rob Prouse I welcome VSRE emails. Learn more at http://vsre.info/ |
|
@rprouse It may take an extra filtering pass, now that I think of it. Initially, I'll filter out all commits under the NUnitFramework directory but that will leave the earlier history before the framework was moved to a subdirectory. That probably explains why my dry run didn't reduce the repo size as much as I thought it should. |
|
I've been thinking a bit more about the split, specifically the idea of renaming this repository after the split. This has been our main repository for a long time now and there are probably hundreds of links to it and probably to issues within it, so I think we should keep the name the same. GitHub redirects I think if we update the description on the front page of the repo along with the README, it will be clear enough what this repo is. |
|
I'm good with keeping the name. I'm still a bit uncertain about keeping the history, even filtered, in the new repo. Do we really need it in two places? |
|
I'd be reluctant to lose history. I find |
|
It looks like there may be a way to amend the commit messages while doing a filter-branch. See: Does that make any sense to you? 😉 |
|
I guess my thinking is that I very rarely need to use old history. After a few months, I imagine the only history I care about would be in the new repo. For that short period, I'd be fine with the extra effort of looking in the old repo. In fact, I've done that already on the rare occasions where I wanted to look at ancient history, back to our SourceForge days. Do you find you often have to go back a long way in the history? I'm generally just trying to find out what broke since the last release. |
|
I do think this is something we need to decide before finalizing the split. We can't add the history if we don't keep it. We could keep it and subsequently delete it, but it's significantly easier to make the decision in advance. |
It can be useful if you come across a weird bit of code. At least you can find out who wrote it. 😉 |
|
Yup. That's exactly what sent me back into the ancient history of NUnit one or two times - who decided to do this crazy thing?!? Still, it has only been one or two times for me. As I read the comments, it seems our views on this split as follows:
It's only coincidence that I'm the guy doing it. :-) But seriously, I'll do it however we decide. Any more @nunit/core-team opinions? Can we make a decision? |
|
I don't do enough work on NUnit for this to really matter, but in other projects I find the history invaluable. Normal use is to trace a line of code back to a bug tracker issue, and work out what the heck the thinking was when it was written. 😉 For that to work, it seems it requires the "most work" options - but to my mind, putting that effort in at this point is justified. 😊 Sorry! |
|
I think full history and updated comments would be nice, but not worth the effort if we are maintaining the history in this repo. It is a bit more work to spelunk in another repo, but we don't do it often. I also find history invaluable at times, that is why I would like to maintain it in this repo so we at least have it somewhere. I would even be fine with option 3. Worst case, Charlie or I can usually remember who wrote something and roughly why 😄 |
|
I guess I see where the different views come from. If you've been working on the project for years, then you probably don't go back very far that often. But if you are relatively newer to it, then you may need to look back to understand something. @ChrisMaddock If you were working on the engine and you needed to do that, would you find switching to the nunit repo to do your research too much of an effort? Note that if I correct the comments on the history in the engine/console repo, they would take you there eventually anyway. My take on the three options is that I'd rather have no history than dubious history. Option 2 is dubious, because the merge comments are incorrect. Option 1 seems dubious as well, because the history is incomplete and the links in merge comments take you to a different repo, perhaps without your realizing what is happening. Option 3 forces you to take an extra step to find the history, but once you are there it's complete and correct. |
|
@ChrisMaddock OTOH, we're willing to do more work if it will make you do more work. :-) |
How do you mean about the history being incomplete? Won't it preserve all commits that touch a file on the retained branch? If it takes you to the correct issue/PR without you realizing, isn't that a good thing? 😉 |
Haha...clever 😉 Not sure I can promise that!
No, sure. But I would need to know that I needed to do that, which future new developers may not.
Agreed! Having links to the wrong issue sounds very confusing! I'm missing the dubious part of option 1, maybe I've mis-understood? I thought option 1 was to edit all the link so that they still linked to the correct issue? All this said, I don't really have any idea how much work this involves - I was imaging it was just a regex passed over the history - I'm not a regular git user! I can see how time may be better spent elsewhere. |
|
Why I call option 1 dubious history...
@ChrisMaddock As far as new guys go, if they are experienced, they know that every repo starts somewhere, with it's first import. If there is earlier history, it's elsewhere. I've run into this in lots of open source projects. OTOH, if they are inexperienced, they will be confused whatever we do. :-) To the level of work... It's certainly doable. More a question of priorities. However, this is a basis for further progress, so I want to do the right thing. |
True - but feels like it would still be best to avoid if at all possible! But then I'm the kind of person who get's upset when he breaks up a class and looses the revision history on a method...this is a different level! 😉 Option 1 still seems the lesser of evils to me, however I don't have much understanding of how much work is involved, and equally, I won't be the person doing the work! So could understand that as a justification for going for option 3. |
|
I'm going to give it a shot anyway. I'll just keep on filtering locally until it looks right. |
This is the biggest split of the bunch! We will initially create separate repos for the framework and the engine plus console. For the moment at least the engine and console will stay together.
We will have to decide on the mechanics. Alternatives...
The text was updated successfully, but these errors were encountered: