This discussion got unexpectedly involved, but It's not like I were trying to
persuade you about anything. I was curious why aren't you employing what
typically proves to be a useful tool, but was not really looking for
justification or reevaluation of your decisions :) Yet, it still strikes me as
odd that you associate an effort or overhead with using a VCS, particularly,
git. Could it be so long ago that you tried it, that the process was indeed
cumbersome? The fact you're referring to it as SCCS kinda hints at that. Some
earlier VCSs were notoriously obstructive to the flow.
Nowadays I, personally, don't think twice about using git regardless of whether
I intend to push the code into a remote repo. Regarding the overhead I, also
personally, consider it pretty much zero. All the benefits like the review of
changes, endless undo, release control, doubling as backup, feature separation,
history analysis, etc. come essentially for free, compromising nothing.
Maybe the core difference in our sentiment lies in the organization of the
development process. To gain the most from the use of a VCS the development
needs to be organized in a compatible way, that is, be structured to some
extent. When working on a personal project there is a strong drive to abandon
any non-essential organization bits which then are seen as restrictive,
unnecessary, "overhead". Either way is feasible, and one good thing about the
software development industry is that many of the process inefficiencies of the
earlier days have by now received rather efficient solutions, quite universally
applicable regardless of the nature of the project. Some of them can even be
trusted :)
I appreciate your having explained the reasoning behind your choices. Also I
now understand the task of figuring out the inner workings of Argyll will not
be made excessively easy for me by too much of VCS tooling.
Cheers,
Nic Nilov.
On May 14, 2022, at 03:14, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
Nic Nilov wrote:
Indeed they exist, but those only keep track on the release scale, that is,
every commit reflects a whole release. This approach is only marginally
useful since the amount of changes between the releases is so large. At
approximately +4000 -2000 LOC changed between minor releases and tens of
thousands of changes between major releases it's just not a meaningful scale
to get a feel of the developments. This also offers no insight feature-wise,
as its just a plain diff of two code snapshots.
Agreed. But checking in and documenting such small scale changes is exactly
the overhead I can't justify for a one person project. Having attempted
this at one stage, my feeling was that 20-30% of my mental capacity was being
used up on this activity. I'd rather use that for solving problems,
researching
solutions and cutting code.
But where is the overhead? Setting up a repo on github and uploading the
sources only takes minutes and pretty much never needs any more attention.
That's not my experience. Making sure the SCCS keeps track of where
code has gone, worrying about what was and wasn't going to be checked in,
as well as breaking up development into small enough pieces that checkins
made sense, really slowed me down. Having to check that the build reflected
what was checked in was an overhead. What happened eventually was that
checkins
got further and further apart, until they weren't worth doing.
Now when there is more than one person involved, the equation changes -
a SCCS becomes an essential tool in communication
I do assume you are using git (or something) locally to track your changes.
It's just one short command away from also keeping the remote copy in sync.
Nope. I tried it, and it was too much overhead.
(And yes, I have been used to using a SCCS when working with a team.)
Where to take it from there is up to you and is all completely optional.
Again, I do assume you are familiar with branching. Although it arguably
offers more benefits for collaborative work, it is also useful for lone
developers just to keep the scopes of work separate and therefore more
manageable. Here is a writeup detailing one branching approach
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow,
but like I said, this all is completely optional and up to taste.
I'm happy to acknowledge the advantages you mention. The learning
curve of a particular SCCS is an big issue for me - it's like trying to run
with one leg tied behind your back, and that learning effort could be put
to so many other uses (i.e. learning a GUI toolkit well enough that I
could code a graphic interface for ArgyllCMS for instance.)
It is more about a kind of a todo list, with the benefit of building up the
context around the original idea. The context can be evolved by your own
elaboration, input from others if you open to that, and technical
conveniences like cross-referencing the code.
I appreciate what you say - there's certainly something in that.
But frankly, I can't afford to spend much energy on possibly future
enhancements to ArgyllCMS - it is a financial dead end at the moment,
so my planning is mainly directed at other projects. My current aim with
ArgyllCMS is to keep it relevant and keep it working. Donations
are very important in allowing me to continue to do that.
All this would change if a company licensed it as the basis of a product
that would pay significant royalties - something that continues to be
threatened,
but (as yet) hasn't eventuated.
Cheers,
Graeme Gill.
