--
You received this message because you are subscribed to the Google Groups "git-tfs-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to git-tfs-dev...@googlegroups.com.
To post to this group, send email to git-t...@googlegroups.com.
Visit this group at https://groups.google.com/group/git-tfs-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/git-tfs-dev/407035f1-276f-4c32-82f7-a24956cbef4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to a topic in the Google Groups "git-tfs-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-tfs-dev/CQQcpYse6Is/unsubscribe.
To unsubscribe from this group and all its topics, send an email to git-tfs-dev...@googlegroups.com.
To post to this group, send email to git-t...@googlegroups.com.
Visit this group at https://groups.google.com/group/git-tfs-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/git-tfs-dev/CAECVvXYYfRWytzU3HHbJ_nvZpv1UUNzpb%3D2QxdiTnwBAwRe3iw%40mail.gmail.com.
That's great to hear that we can keep a good thing going.
When I originally forked, my plan was to rip out the stuff I didn't need like VS2012, 2013, cake, etc. However, since I have your support to make some larger changes, I'm willing to support these tools in an effort to keep with the spirit of the project: Accessibility and stability. I will be discarding my changes so far as most of them removed tools that I will now need.
I think before we decide the best way to share my changes, we should probably establish some of the changes I had in mind. You can then decide if you are comfortable with the direction that I plan to work towardsRe-architecture
- All core objects will be refactored to separate assembly (GitTfs.Core). The main reason is to decouple the core functionality from the command line. However, this could pave the way for a GitTfs NuGet package that could facilitate others integrating GitTfs in their own apps if the demand arises.
- Namespaces within GitTfs.Core will be defined more clearly, creating a separation between Git and TFS components. The types that bridge the two will remain at the highest level, referencing only components in deeper namespaces
- Util classes will be consolidated into the various namespaces of which types they operate on. This will hopefully create stronger boundaries between types resulting in better test isolation
- Where possible reduce the amount of state fields/properties on core types.
Code Cleanup
- I saw that general project goal was to improve duck-typing throughout a few key areas. I follow traditional clean code and clean architecture in practice as well as the SOLID principles so self documenting code is on the forefront of my concerns. Type names will undergo some significant changes to increase readability
Maintainability & Contributions
- I'm not sure if the .SLN is intended to build in the IDE,but I was not able to build out of the box from a fresh clone. TFS binaries for 2012 and 2013 were missing and did not exist in NuGet from what I could tell. I'd like to simplify the build process and eliminate any additional steps that developers will need to do to contribute. This will hopefully encourage others to step in and keep things moving forward.
- Introduce a basic .editorconfig with accepted styles
Performance
- Investigate and possible implement fast-clone as suggested. Thank you for the tip!
- Look into possible async/await and multithreaded operations
- Fix a bug I recently discovered, (which inspired me pick up this project) where large log files cause universally poor performance. My log file was 171mb because I have scheduled git-tfs fetches on all of my repos. The performance of System.Diagnostic.Trace.* methods, appear to be dependent on the size of the log file. even the help command is affected.
Wishlist
- I'd like to look at the possibility of removing NLog altogether and replacing it with a lightweight, custom output console/file appender. The formatting will remain the same so it will have a consistent L&F but we'll loose the Nlog dependancy.
- Investigate options for fetch/clone progress indicator
- Better remote tracking. We had issues getting "commits ahead/behind" from TFS remote. This sometimes work but we found we had to fake a git remote to get this working.
- Any outstanding items preventing V1 release
As you can see, most of these changes are not going to be trivial. If I am successful, the visibility of the main fork will get these improvements to people quickly. That being said, I am also very conscious that this constitutes a significant effort on your part and do not wish to undermine your goals or evolve the project into something that you and the community do not want.If you are willing to offer me access to the main fork and implement the above changes I would certainly be happy to work there as it is probably easier for me. Otherwise I will re-fork and start there.
To view this discussion on the web visit https://groups.google.com/d/msgid/git-tfs-dev/CAEPDJGyxQycH0npbaofuLopsh3z5rbeFPdyQkGj2w7qwjHh6Fw%40mail.gmail.com.
Tooling like cake and nlog are very much OK to replace. They were convenient at a particular time, but aren't inherently required. With cake especially, it would be worth replacing some or all of the things it did. IIRC it helps with the release process and with running automated tests. I think it would make sense to start with other changes first to build momentum, but it's fair to replace tooling with things you'll be able to work with more easily..
I don't follow this point. Do you have an example or two of classes that you'd like to change? It's probably all good, just a jargon misunderstanding on my part. ;)
If you're talking about the mirroring of TFS classes in GitTfs interfaces and types, that's intentional so that a single git-tfs.exe can work with any VS version.
You're welcome! This might not result in immediate end-user performance improvements. But it will make things better on large repositories. For example, git fast-import will produce a single packfile for each session instead of loose objects. Git itself will perform better when the repository has more packfiles and fewer loose objects in .git/objects.
One of the things I tried to do with git-tfs was to build a single exe that would work with any (or almost any) version of VS. It drives me crazy when dev tools require a different installation depending on which version of VS you have. So, git-tfs has all of its core stuff in one assembly (git-tfs.exe) and one assembly per supported VS version. Some code works with One of GitTfs's VS assemblies will be loaded at runtime. I'm quite happy with this at a high level. The implementation seems to work well enough, but the particulars aren't super important. I'm interested in preserving the "only one git-tfs package" property. One of the side effects of the current layout is that you can't build the entire SLN if you don't have all of the supported versions of TFS installed. This is definitely a pain point, and I'd be interested in getting the dev side sorted out so that that's not the case. It could be that all of the VS projects are disabled by default, or they have conditional build rules so that they're skipped if their deps aren't installed, or whatever. Like I said earlier, my main goal in this area would be to keep distributing just one git-tfs package regardless of the target env.
To unsubscribe from this group and stop receiving emails from it, send an email to git-t...@googlegroups.com.
To post to this group, send email to git-t...@googlegroups.com.
Visit this group at https://groups.google.com/group/git-tfs-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/git-tfs-dev/407035f1-276f-4c32-82f7-a24956cbef4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "git-tfs-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-tfs-dev/CQQcpYse6Is/unsubscribe.
To unsubscribe from this group and all its topics, send an email to git-t...@googlegroups.com.
To post to this group, send email to git-t...@googlegroups.com.
Visit this group at https://groups.google.com/group/git-tfs-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/git-tfs-dev/CAECVvXYYfRWytzU3HHbJ_nvZpv1UUNzpb%3D2QxdiTnwBAwRe3iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "git-tfs-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to git-t...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to git-tfs-dev...@googlegroups.com.
To post to this group, send email to git-t...@googlegroups.com.
Visit this group at https://groups.google.com/group/git-tfs-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/git-tfs-dev/a9ca50ac-8169-403d-affb-38e1ba51e3ac%40googlegroups.com.