Re: versioning file system
On 10/28/18 10:40 PM, Erik Christiansen wrote:
On 26.10.18 13:05, David Christensen wrote:
When programming, I tend to do check-in's when I make some kind of progress
(ideally, the code builds and the test suite passes).
Yup, the smaller edits of bugfixes aren't going to threaten code stability.
+1 Working solo on personal stuff, I have learned to be less worried
about checking in broken make and test on the head. The key is
finishing and doing the final commit, tag, build, test, install, and
release before I get distracted by the next thing.
The trap is when I work for a while, make some progress, make a wrong turn,
and then make a mess. A versioning file system makes it easy to get back to
"make some progress" and try a different turn.
Yes. If the major hack can be limited to one file, I've been known to
rely on Vim's undo capability to buffer all the changes long enough for a
build and test.
+1
That could perhaps be extended to several editor
instances for a couple of files, for a quick but disruptive tentative
test of a divergent approach.
The more robust way is though to develop on a VCS branch, check in prior
to jumping off the cliff, and merge back to trunk when it's all sorted
and tested.
+1 Definitely branches for anything non-trivial.
The compromise is to do a "work in progress" check-in prior to risky turns.
Yup, but risk can grow after initial edits reveal that additional
structural changes are needed in order to enable the revised strategy to
be completely implemented.
That's when it is time to create a branch and move the working files over.
In response to that late awareness, I've been
known to ifdef out the old, to leave it in the file for recovery if a
massive stone ball comes rolling down the path I've hacked through the
jungle.
I do Perl:
=pod
=cut
Cut and paste below __END__
And yes, if CVS is the VCS you're most familiar with, then it's still
fit for use. Traffic on the ML is rare now, but there is still some
legacy use out there, and I use nothing else for my own versioning,
having used it for multi-team international software development for
many years. Its automatic merging capability alone is a dream.
OK, git is quicker and preferred for big projects, but for small teams
of greybeards who were weaned on it, CVS is still fine.
Okay.
(And if you're
fumble-fingered and flummoxed by cryptic error messages, then take a
snapshot of the entire repository before any major operation on it, so
that deletion and replacement entirely undoes any embarrassing stuff-up.
+1
Alternatively, copy aside and/or backup the working directory.
David
Reply to: