Evo: Version control that works the way you think
1–10 of 46 posts
Re: Evo: Version control that works the way you think
#2> Large file support built-in
You've got my attention.
How does "bringing 2 copies into 1" (aka merge) work?
For big media files, lock / last timestamp is OK.
...but is there anything that helps merge changes in text? Not saying lock/timestamp for *everything* is bad, but IMHO, intelligent auto-merge of text is a main reason git is good.
Re: Evo: Version control that works the way you think
#3It would help a lot to post a video or gif, showing how it deals with 3 features being merged with a lot of conflicts. It really has potential to be awesome, but you gotta show how.
Re: Evo: Version control that works the way you think
#4Darcs was probably the most interesting VCS in this space. It made a lot more sense because it was more about managing patches (or features) instead of history that we do now with git.
IIRC Darcs had a lot of momentum with it until there was a problem discovered with it's algebra that allowed itself to go into an infinite loop. And then it died.
At least with git, I can think in terms of DAGs which should be in the knowledge of any serious senior software engineer.
Re: Evo: Version control that works the way you think
#5That sure is a reasonable-looking user interface.
Re: Evo: Version control that works the way you think
#6Darcs was probably the most interesting VCS in this space. It made a lot more sense because it was more about managing patches (or features) instead of history that we do now with git. IIRC Darcs had a lot of momentum with it until there was a problem discovered with it's algebra that allowed itself to go into an infinite loop. And then it died. At least with git, I can think in terms of DAGs which should be in the k…
I don't know if managing patches makes more sense than managing revisions. The truth is that you need both.
Sometimes you are authoring patches, and reviewing patches. But sometimes you are releasing/trying/building revisions, and you are releasing revisions.
Moving to the dual representation fixes some issues and brings its own. I think the only reason why some people think it is better is because they haven't used it long enough to get frustrated by the new issues, the way they had time to be frustrated by the old dual issues.
Re: Evo: Version control that works the way you think
#7LICENSE 404, though Readme says MIT.
Re: Evo: Version control that works the way you think
#8> evo workspace merge
wtf does that even do. I have no idea if it does what I think because I have no idea what it does.
'push' is a hundred times more clear than this obscure incantation.
Re: Evo: Version control that works the way you think
#9I'm definitely interested in the promise here. But it seems very early days.
I'm sceptical about the whole "make a workspace for a feature, then code, then merge" workflow. For me in practice work often doesn't follow that linear path, I don't really know what feature will be finished and ready for committing until done.
One very surprising thing I have learnt about git is that it is intuitive for some people. Whereas maybe half of its users, including me, will never really get it, even after decades of use. So I am also skeptical about broad claims of intuitiveness.
I think the problem of creating a truly user friendly distributed version control system CLI is enormously challenging and requires a lot of deep thought if it is going to meet the needs of a wide range of software development practices. Looking at the DESIGN.md does not convince me they have gone deep enough in that analysis. It has a bit of a blase "it's just common sense that it should work like this!" and I'm pretty certain it's not so easy.
Re: Evo: Version control that works the way you think
#10Darcs was probably the most interesting VCS in this space. It made a lot more sense because it was more about managing patches (or features) instead of history that we do now with git. IIRC Darcs had a lot of momentum with it until there was a problem discovered with it's algebra that allowed itself to go into an infinite loop. And then it died. At least with git, I can think in terms of DAGs which should be in the k…
I don't know if managing patches makes more sense than managing revisions. The truth is that you need both. Sometimes you are authoring patches, and reviewing patches. But sometimes you are releasing/trying/building revisions, and you are releasing revisions. Moving to the dual representation fixes some issues and brings its own. I think the only reason why some people think it is better is because they haven't used…
I don't know either.
Managing patches or features seems to be easier to think about: "I want feature X in this build but not Y for reasons even though Y was in the last build..."
But language (software or otherwise) doesn't really work that way.
You could imagine a novel written using a VCS where in one branch of the novel a main character lives throughout the novel dying at the end. In another branch, that character dies in chapter 1. Now try to merge the two branches automatically.
Sure, you might get a novel, but the character lives on after chapter 2 nonsensically.
That's the same issue with programming languages. "Syntax" is not the same as "Functionally Coherent".