4 ms·

I think a better solution is to have both features in branches, and have a 3rd branch which allows realtime switching between the 2. a nice upside is that you

I think a better solution is to have both features in branches, and have a 3rd branch which allows realtime switching between the 2. a nice upside is that you can merge changes to each feature up into the "combined" branch as they get stable, to test side by side. when you finally finish, you can leave feature a behind by merging b into your release, or vice versa. or maybe even merge both into mainline. sorry, the point I was trying to make is that cheap branching and merging is still an easier way to manage this situation than just ignoring branches altogether.

axod 17y ago
In what way easier? A: Create separate branches, manage merging/updating unrelated changesets. B: Create 2 implementations of something in code, and manage nothing. I guess it depends on how easy it is to isolate the part you want to create 2 implementations of, so it may depend on what language you're using as well as how you architected things. Branching+Merging just seems like something extra I have to do, manage, and remember. Like filing. And I still can't see what benefit it gives for many cases. But that's fine I think... I just don't get it. Maybe I'm too old ;)