You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem I have, and it's nothing to do directly with this wonderful tool, is that I have, literally, over a hundred thousand verified.txt files. That isn't the problem itself; Verify handles these files perfectly. The problem is when it comes to PRs. It is often the case that a commit might change up to 100% of these files, which kills the PR process stone dead (at least on github.com - I've had more success on github desktop).
But why so many files? My project, Vogen, is a source generator for Value Objects. The reason it has so many snapshot files is that runs permutations of many different features and concepts. For instance, the type augments classes, structs, records, record structs, each of those as public or internal, each with or without various user provided methods, such as ToString, Validate, Normalize, each with any combination of converters or serializers, e.g. TypeCoverter, Dapper, EFCore, System.Text.Json, Newtonsoft.Json, LinqToDB. And each of those for net461, net48, netcoreapp3.0, netcoreapp3.1, net5, net6, and net7.
An idea that popped into my head, and I understand it's not without some serious considerations, is, instead of writing directly to disk, we can swap that out for some kind of virtualized abstraction that can write to a zipped file.
I'm sure such an abstraction already exists, but clearly, the biggest issue is diffing: where would the received files go? how would we tell the diff tool(s) to compare the differences?
Also, performance is another issue. I think for this to be feasible, the whole zip file would have to be manipulated in-memory.
There's probably tons of other problems that I haven't thought about, but I'm just drawn to the goal of having one zip file instead of 102,000 verified.txt files.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The problem I have, and it's nothing to do directly with this wonderful tool, is that I have, literally, over a hundred thousand verified.txt files. That isn't the problem itself; Verify handles these files perfectly. The problem is when it comes to PRs. It is often the case that a commit might change up to 100% of these files, which kills the PR process stone dead (at least on github.com - I've had more success on github desktop).
But why so many files? My project, Vogen, is a source generator for Value Objects. The reason it has so many snapshot files is that runs permutations of many different features and concepts. For instance, the type augments classes, structs, records, record structs, each of those as public or internal, each with or without various user provided methods, such as ToString, Validate, Normalize, each with any combination of converters or serializers, e.g. TypeCoverter, Dapper, EFCore, System.Text.Json, Newtonsoft.Json, LinqToDB. And each of those for net461, net48, netcoreapp3.0, netcoreapp3.1, net5, net6, and net7.
An idea that popped into my head, and I understand it's not without some serious considerations, is, instead of writing directly to disk, we can swap that out for some kind of virtualized abstraction that can write to a zipped file.
I'm sure such an abstraction already exists, but clearly, the biggest issue is diffing: where would the received files go? how would we tell the diff tool(s) to compare the differences?
Also, performance is another issue. I think for this to be feasible, the whole zip file would have to be manipulated in-memory.
There's probably tons of other problems that I haven't thought about, but I'm just drawn to the goal of having one zip file instead of 102,000 verified.txt files.
Beta Was this translation helpful? Give feedback.
All reactions