Author Topic: A version control system for embedded work, which doesn't need a PhD  (Read 52185 times)

0 Members and 2 Guests are viewing this topic.

Online PlainName

  • Super Contributor
  • ***
  • Posts: 8885
  • Country: 00
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #125 on: August 12, 2021, 10:17:50 pm »
OK, I think we are done here since we are very close to name calling. Although, pedantically, it doesn't take a genius to decode that passive aggressive stuff :)

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4668
  • Country: us
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #126 on: August 13, 2021, 01:21:23 am »
Quote
It's amusing to see that the OP explicitely asked for a simple, not requiring a PhD solution, and the thread is getting increasingly hard to follow. It will soon take a PhD to even understand what people are saying.
I was thinking exactly the same thing!
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #127 on: August 13, 2021, 02:00:43 am »
I for one am never passive aggressive; it is always a miscommunication if it appears that way.  When aggressive, I'm always directly confrontational; I don't play social games.

It needs the sequential version numbering for each commit.
That's the part I don't understand.

Quote
Quote
Internally, use the commit hash.  Externally, use the tag.
I'm not sure I follow, sorry. Internal to what?
Perhaps an example will clarify.

Consider Teensyduino commit 224b97bb3ff408ce60dd6f7bde13da7c20c825cf.  This is a fixed reference to this particular commit.

This commit is tagged 1.51.  Tags can be removed and edited if necessary.

Each tag has several properties, including author and date.  For example, if you want the list of tags in the current project, sorted according to date, use git tag -l --sort=creatordate.  Each tag refers to exactly one commit, via the commit hash.

Within the code and development logs, you refer to commit hashes.  For example, a commit message can say that "This commit fixes a race condition caused by interactions between commit #hash and commit #hash."

In all other communications, including user-visible information, refer to a specific tag.   Just remember that tags can be modified, commit hashes not so much.

Quote
Suppose the reported version is 1.0.123 where 123 is the revision reference. It seems to me that you're suggesting that to find the commit I need to cross-reference that 123 using the other repo to find the hash which I can then do a search on in the project repo.
No, I'm saying the commit at which the source tree corresponds to version 1.0.123 is tagged "1.0.123".

The only reason you would need the central database is when the entire project is distributed across several git trees, and you want to keep the tags synchronized.

An alternate method would be for each subproject/part to use a version prefix in their tag.  For example, let's say you have "core", "net", and "plugins" parts, developed in local git repos, as part of a single product.  When version 1.2.34 is to be tested, each subproject tags the final commit using the prefixed version –– so core-1.2.34, net-1.2.34, and plugins-1.2.34 ––, while in the central product tree, after working out any merge conflicts, the final commit is tagged 1.2.34.

One can run git fetch -t to only update known tags from upstream.

Quote
Almost. Each commit needs a version reference which is higher than the previous one (but don't need to be monotonic). 1, 2, 7, 12, 15 - that kind of sequence is fine.
We're crossing terms here.  1, 2, 7, 12, 15 is monotonic but not sequential.  1,2,3,4,5 is monotonic and sequential.

A central "versioning" git repository is only needed if the version numbers need to be centrally managed.  Normally, you use e.g. git fetch -t ; git tag --sort=creatordate -l '--format=%(creatordate:iso) tag: %(refname:short)' (aliased or in your own personal helper script) to list the tags known locally and upstream.  (git fetch -t only updates the tags for the current repo from upstream.)

Quote
If you're going to have a single repo then git has some downsides and version control that is designed to work this way is just simpler and easier to use.
No, the existence of the central "version" git repository is to maintain duplicate information that needs to be synchronized across multiple distributed git trees, without introducing conflicts, in text form.

Quote
Quote
The one thing that gives me pause is the need for monotonically increasing commit identifiers, as I don't see why
Because it tells you this thing came after that thing. A git hash has no meaning outside the repo, so you can't tell from a hash whether this version came before or after that version without looking it up in the repo.
Run git show -s '--format=format:%ai %H %d' commits or tags | sort -g
or put that into a shell script or function, and it will list the date and timestamp of each commit or tag ("YYYY-MM-DD HH:MM:SS +hh:mm" format), followed by the full commit hash, followed by the tag(s) for that commit.  You don't need to supply full commit hashes either, any unambiguous prefix will suffice.  Tags do need to be complete.

Quote
Quote
Isn't a commit hash and the timestamp of the commit sufficient, or even better?

No. "When you select 'about', what does the version number say?"
The tag for that version, of course.  That's their very purpose.

Quote
A date stamp and hash is essentially a GUID, and you know how simple they are to trot off the tongue!
Yeah.  I most definitely do not want users or testers to deal with commit hashes.  They'll never get them right.
« Last Edit: August 13, 2021, 02:04:05 am by Nominal Animal »
 
The following users thanked this post: newbrain, DiTBho

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2499
  • Country: us
  • Yes, I do this for a living
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #128 on: August 13, 2021, 02:23:14 am »
Perhaps an example will clarify.

Consider Teensyduino commit 224b97bb3ff408ce60dd6f7bde13da7c20c825cf.  This is a fixed reference to this particular commit.

This commit is tagged 1.51.  Tags can be removed and edited if necessary.

Why would you remove or edit a tag? Coming from SVN, my view is that tags are immutable. That's the convention, of course, not enforced by SVN but TortoiseSVN has an opinion.

I admit that I've fucked up making a tag, but I noticed it immediately and deleted it and replaced it with the correct tag. But that's the exception.
 

Offline emece67

  • Frequent Contributor
  • **
  • !
  • Posts: 614
  • Country: 00
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #129 on: August 13, 2021, 09:39:54 am »
.
« Last Edit: August 19, 2022, 04:36:30 pm by emece67 »
 
The following users thanked this post: DiTBho

Online PlainName

  • Super Contributor
  • ***
  • Posts: 8885
  • Country: 00
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #130 on: August 13, 2021, 11:08:52 am »
Quote
I for one am never passive aggressive;

Wasn't suggesting you were - sorry if I appeared to do so. My comment was aimed at someone else - not the OP, you might say.
 

Online PlainName

  • Super Contributor
  • ***
  • Posts: 8885
  • Country: 00
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #131 on: August 13, 2021, 11:29:52 am »
Quote
No, I'm saying the commit at which the source tree corresponds to version 1.0.123 is tagged "1.0.123".

OK, I think I am with you now. The tag should be fine.

Quote
We're crossing terms here.  1, 2, 7, 12, 15 is monotonic but not sequential.

Possibly. I think it depends on whose definition you go with, but the important thing is that we know what is meant here.

Quote
Quote
Quote

    Quote

        The one thing that gives me pause is the need for monotonically increasing commit identifiers, as I don't see why

Quote
    Because it tells you this thing came after that thing. A git hash has no meaning outside the repo, so you can't tell from a hash whether this version came before or after that version without looking it up in the repo.

Run git show -s '--format=format:%ai %H %d' commits or tags | sort -g
or put that into a shell script or function, and it will list the date and timestamp of each commit or tag

Yeah, but you're not going to be running git every time you look at some version output. When you're working on the repo, fine, but the point of embedding the version in the product is to tell you when looking at that (or being told about it) what that is.

Thanks for persevering. It doesn't make me more amenable to git (there are other bigger things already mentioned that mitigate against), but it does suggest a way to make it a better fit when I do use it  :-+
 

Online PlainName

  • Super Contributor
  • ***
  • Posts: 8885
  • Country: 00
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #132 on: August 13, 2021, 11:47:09 am »
Quote
I suppose this depends on the usual scenario each developer works. In a mainly linear history scenario, sequential version numbers can give clues about what went after what. In a highly branched-merged history scenario, such clues are no longer valid

Yes, indeed. Where I find it useful is within a branch rather than across branches, but I tend towards linear branches (that is, go off on a branch and either merge it to continue or discard it if it didn't work out).
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #133 on: August 13, 2021, 12:47:46 pm »
Why would you remove or edit a tag? Coming from SVN, my view is that tags are immutable. That's the convention, of course, not enforced by SVN but TortoiseSVN has an opinion.

I admit that I've fucked up making a tag, but I noticed it immediately and deleted it and replaced it with the correct tag. But that's the exception.
That's exactly my view too.

In a mainly linear history scenario, sequential version numbers can give clues about what went after what. In a highly branched-merged history scenario, such clues are no longer valid and (sequential) version number 1234 can still contain issues long ago fixed in (sequential) version 567 (that lies in another branch not yet merged with that of 1234) and such 567 version can contain new features not yet included on 1234. On this scenario you may need a means to distinguish "internal" (meaningful to developers) commits from "external" (meaningful to customers) ones. Tags serve this purpose, but obviously somebody must decide what commits are meaningful/prepared/tested/contains_the_desired_features to customers and manually add the tag (and what tag to add) to them. And developers need a means to know what issues were fixed when, but for this purpose a simple sequential version number can be useless, they need to see the whole picture.
Well put!

I see git repositories as databases, branches as evolving workspaces, tags as easily human-referenceable markers, and commit hashes as (immutable) identifiers for specific changesets.  All of these have metadata.

Quote
We're crossing terms here.  1, 2, 7, 12, 15 is monotonic but not sequential.
Possibly. I think it depends on whose definition you go with, but the important thing is that we know what is meant here.
Quite.  (I like to dabble with monotonic functions (they have useful properties when implemented in computer programs), and occasionally integer sequences like those in The On-Line Encyclopedia of Integer Sequences, so I assumed these definitions were universally agreed on, sorry.)

Quote
Run
    git show -s '--format=format:%ai %H %d' commits or tags | sort -g
or put that into a shell script or function, and it will list the date and timestamp of each commit or tag
Yeah, but you're not going to be running git every time you look at some version output. When you're working on the repo, fine, but the point of embedding the version in the product is to tell you when looking at that (or being told about it) what that is.
True.

A common approach is to use either a header file (say, version.h, often with an object file which declares those values in exported variables for object file examination) which defines the version string, build date, version number components (minor, major, revision) as preprocessor machor; or those preprocessor macro definitions (say -DVERSION_STRING="1.2.3" -DVERSION_MAJOR=1 -DVERSION_MINOR=2 -DVERSION_REVISION=3 -DBUILD_DATE=$(NOW) are passed to the compiler at build time), based on the build machinery.  Both Autotools and Cmake have facilities for implementing such.

If a header file is used, then the commit that updates that header file is (in my opinion!) the best one to be tagged with the new version; it should also be done as the last step after testing.  (For testing, I'd use a " (testing)" suffix in the version string, keeping the numeric version macros intact.  So, in practice, the testing/stabilizing cycle before production both begins and ends with a commit modifying such a header file.)

Thanks for persevering. It doesn't make me more amenable to git (there are other bigger things already mentioned that mitigate against), but it does suggest a way to make it a better fit when I do use it  :-+
Excellent; that is in my opinion the best possible outcome.

I am not interested in changing anyones opinion about git or any other tool, only that they have the information and understanding of that tool to wield it effectively, and make up their own mind.  This most definitely includes things like Linux for me; I'm not interested in its popularity, only that those who choose to use it can wield it to maximum effect with minimum effort.  After all, the reason I like Unixy stuff, is that it lets me choose/build my own workflows, instead of forcing any specific one on me.
 

Offline sokoloff

  • Super Contributor
  • ***
  • Posts: 1803
  • Country: us
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #134 on: August 13, 2021, 02:15:01 pm »
Quote
Commits happen often many times a day.

Yes. So?

Why are  sequential version numbers NOT applicable to developers when they are to everyone else? Why don't developers want to know this came before that without having to look it up? A cynic would suggest it's because it's too much hassle to achieve, so therefore they're convinced they don't want or need the ability.
I think there are two factors here.

On the practical: a developer using git is (at least on average) familiar enough with git that "I can just ask git which came first" is every bit as natural as "I think I'll open this file with my text editor to see what's inside it".

On the theoretical: git is designed to be used in a fully distributed, often offline, fashion. If you and I are on different islands (or airplanes) with no way to communicate to each other, we can both continue to use git (locally) perfectly well and only later when we have work to share with each other, we can accomplish that (without changing the commit identifiers that each of us used). This is where the cynic might argue "well that's a dumb choice for git to have made; they shouldn't have allowed offline, decentralized usage because that means that I have to ask git which commit came first". That is an argument about a tradeoff between two product capabilities at that point.
 

Online PlainName

  • Super Contributor
  • ***
  • Posts: 8885
  • Country: 00
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #135 on: August 13, 2021, 02:44:53 pm »
Quote
The On-Line Encyclopedia of Integer Sequences

!

That's a rabbit hole to fall down.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #136 on: August 13, 2021, 04:36:20 pm »
Quote
The On-Line Encyclopedia of Integer Sequences

!

That's a rabbit hole to fall down.
Very much so.

But to tie it to this particular thread, one doesn't need a PhD in mathematics to find it very useful.  For example, given two perfect binary search trees,

with \$n = 2^{N-1}\$ to \$n = 2^N - 1\$ nodes (i.e., depth of the tree is \$N\$, \$N = 3\$ in the above illustration), we have
$$\begin{aligned}
i(k, N) &= \left( k - 2^{\lfloor \log_2 k \rfloor} \right) 2^{N - \lfloor \log_2 k \rfloor} + 2^{N - \lfloor \log_2 k \rfloor - 1} \\
k(i, N) &= \frac{\operatorname{b}\left( i + 2^N \right) - 1}{2} \\
\end{aligned}$$
where \$\operatorname{b}(x)\$ divides integer \$x\$ by its largest power of two factor (and for nonzero positive \$x\$ is always odd), i.e. right-aligns the nonnegative integer binary \$x\$.

It turns out that \$\operatorname{b}(x)\$ is OEIS A000265, \$i(k, N)\$ are subsequences of OEIS A131987, and \$k(i, N)\$ are subsequences of A101279.

Similar to using different version control systems, I can use OEIS as a different reference for these sequences, and refer to them in the documentation, instead of spending a couple of thousand words explaining exactly how the formulae work.  (I also have unit test programs that verify the sequences and orders both using the formulae above, as well as via brute force (re-sorting monotonically increasing sequences of integers), that can be easily amended/converted into microbenchmarks if needs arise.)

In a scientific/engineering organization, that would probably be appreciated, since it makes citations and peer review easier.  In a software house (that only uses the above to speed up access to very large (storage, not in-memory) pre-prepared binary search trees by collecting groups of levels into a single sector, enabling optimum caching patterns, the OEIS references are wasted effort, and the formulae plus the unit tests are better fit to the workflow to prove their fitness for purpose and as documentation to other developers.  (Maybe one might add one-liners with the OEIS links as a courtesy of interested developers, but as a footnote only.)

I definitely don't have the math-fu to attack integer sequence problems in general –– heck, I rely on Maple, Sagemath, Maxima for my symbolic math needs, and can barely do calculus on polynomials; I have no hope of remembering outhand any special functions or their behaviour, just like I use man pages for standard C library interfaces, because I just don't trust my memory to remember the nitty details correctly by rote ––, but I know enough to use them, and where to look for deeper details if need be.  Similarly, I'm definitely not a git power user; I only know enough to fulfill my own needs.  I've just "kept my eyes open" for different patterns that projects that seem to work well (complaints about the workflow concentrated on human goofs, not technical issues), and for patterns that seem to lead to issues; and above, I've tried to describe how those projects I've seen use git efficiently, especially tags and branches.

So, I don't think one needs a proverbial PhD in git to use it effectively.

Yet, simply porting ones workflow from one VCS to git is unlikely to be very effective.  Workflow efficiency does depend on the tools you use.  In my opinion, git is one of those tools you want to first look around at how others are using it, and evaluating their patterns based on how well it seems to work, and how well it could be adapted to ones own use.  This is because it does not have any specific work flow it is designed to adhere to.
Therefore, real-world experience is much more valuable than theoretical in-depth knowledge about these tools.

The same seems to apply to quite a few Unixy tools as well. awk and make are excellent examples of this: even simple templates can be tremendously useful, if you know the basic idea and operational principles (like rules for makefiles, and record-based rules and field-based access in awk), examine well-working scripts (as well as avoid patterns that you see in not-so-well working ones), and just consult the manuals for further in-depth details without trying to memorize anything.  I've written/edited at least a thousand Makefiles along the years, and I still cannot remember whether to use $^ or $< when I want all prerequisites or only the first prerequisite.  I consult the manual for such.  (And I'm pretty fast at it, too: it takes less time than me babbling a normal social sentence out loud.)

I also do not memorize any of the more complex git commands shown in my previous posts.  I use shell aliases and/or functions (if specific to some workflow or task, sourced via a helper shell script), or plain shell scripts in $HOME/bin (which is first in my $PATH, thus preferred over other locations in $PATH).  Many of them contain just the shebang line (#!/bin/bash or #!/bin/sh or #!/bin/dash, depending) and a single exec command... "$@" ... line.
« Last Edit: August 13, 2021, 04:38:45 pm by Nominal Animal »
 
The following users thanked this post: DiTBho

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 17826
  • Country: fr
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #137 on: August 13, 2021, 05:51:09 pm »
Quote
It's amusing to see that the OP explicitely asked for a simple, not requiring a PhD solution, and the thread is getting increasingly hard to follow. It will soon take a PhD to even understand what people are saying.
I was thinking exactly the same thing!

 ;D
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 6464
  • Country: nz
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #138 on: August 13, 2021, 09:11:20 pm »
In a highly branched-merged history scenario, such clues are no longer valid and (sequential) version number 1234 can still contain issues long ago fixed in (sequential) version 567 (that lies in another branch not yet merged with that of 1234) and such 567 version can contain new features not yet included on 1234. On this scenario you may need a means to distinguish "internal" (meaningful to developers) commits from "external" (meaningful to customers) ones. Tags serve this purpose, but obviously somebody must decide what commits are meaningful/prepared/tested/contains_the_desired_features to customers and manually add the tag (and what tag to add) to them. And developers need a means to know what issues were fixed when, but for this purpose a simple sequential version number can be useless, they need to see the whole picture.

100% this
 
The following users thanked this post: DiTBho

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11331
  • Country: fi
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #139 on: August 14, 2021, 09:56:47 am »
In any project which is worked with teams more than say 2-3 people; i.e., something where version control really matters, there is a lot of parallel work going on all the time. You don't work in shifts, you may have 10 people working at the same time and combined their outputs regularly (sometimes once a day, sometimes it might take months before you merge).

How is it even possible to apply sequential numbers and say which piece of work become before something else? And even if you force such behavior, like SVN does, is such numbering helpful at all? I'd say it's misleading, giving appearance of a sequential process when it's a parallel process.

It's equal to printf()ing from multiple threads so that the characters mix up to complete gibberish.

This is also why I never found any use for the SVN's revision number.
 
The following users thanked this post: newbrain, DiTBho

Offline magic

  • Super Contributor
  • ***
  • Posts: 8069
  • Country: pl
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #140 on: August 14, 2021, 11:11:55 am »
Ahem. Lots of projects rebase their feature branches before merging to master to obtain a clean and logical changelog, even if a fake one ;)
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #141 on: August 14, 2021, 11:24:09 am »
In any project which is worked with teams more than say 2-3 people; i.e., something where version control really matters, there is a lot of parallel work going on all the time. You don't work in shifts, you may have 10 people working at the same time and combined their outputs regularly (sometimes once a day, sometimes it might take months before you merge).

How is it even possible to apply sequential numbers and say which piece of work become before something else? And even if you force such behavior, like SVN does, is such numbering helpful at all? I'd say it's misleading, giving appearance of a sequential process when it's a parallel process.

It's equal to printf()ing from multiple threads so that the characters mix up to complete gibberish.

This is also why I never found any use for the SVN's revision number.

Yes this holds true...

They are different

The folk wants a simple tool to a simple job.

Without deep understanding their differences... hard to choose.

IMHO this case holds pretty well with RCS.

I do it today on my master workstation 99% cases.

GIT is meant to a large crowd of devels and changes..

This it not a GIT case - RCS should  do it fine

Paul
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 6464
  • Country: nz
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #142 on: August 14, 2021, 11:28:59 am »
Git is great for large and busy projects.

But it doesn't provide any disadvantage for simple projects with a single developer.

With git you don't even have to set up a server. Just "cd myProject; git init". That's a big win before you even make the first commit.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11331
  • Country: fi
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #143 on: August 14, 2021, 12:29:01 pm »
In a small project with not many commits tagging almost every commit is not a lot of extra work. Then you get exactly the sequence you want.
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 7760
  • Country: nl
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #144 on: August 14, 2021, 12:37:52 pm »
There's also the mental load of juggling different methods, likely you will have to learn some git at some point regardless ... it's ubiquitous.

If you're smart enough that learning and mentally juggling slightly different tools so you can apply the optimal one saves you time, that's great. Lesser gods can hammer in the screw for the best use of their time.
 
The following users thanked this post: newbrain

Online PlainName

  • Super Contributor
  • ***
  • Posts: 8885
  • Country: 00
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #145 on: August 14, 2021, 12:43:10 pm »
Quote
In any project which is worked with teams more than say 2-3 people

At one such client we didn't have a problem that I can recall. It was a big project and involved work occurring in two quite distanced locations with multiple developers.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 6097
  • Country: gb
  • Doing electronics since the 1960s...
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #146 on: August 15, 2021, 06:28:34 am »
This is not a great thread for recruiting people to using VCS ;) which is what everybody is telling me I should be doing.

It confirms the very reasons I have been avoiding it. Sole coder, working alone except for defined "plug-in" tasks, and needing regular backups of the repo so why not just do regular backups of the project?
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 6464
  • Country: nz
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #147 on: August 15, 2021, 07:37:20 am »
This is not a great thread for recruiting people to using VCS ;) which is what everybody is telling me I should be doing.

It confirms the very reasons I have been avoiding it. Sole coder, working alone except for defined "plug-in" tasks, and needing regular backups of the repo so why not just do regular backups of the project?

Because using a VCS to make commit is enough easier than making and naming yet another copy of the project that you can do it for every minor change.

Because a VCS lets you easily see the history of what happened, compare versions, find out what code change happened in what modification.

Because git lets you easily work on several different new ideas independently, put something aside temporarily and then come back to it, make experimental changes and abandon failed experiments without a permanent record (if you don't want one)

Because a VCS uses much less disk space in total than dozens or hundreds of copies of the project. The git repository of the LLVM project, with currently 396548 commits over 18 years, uses less disk space than a single checkout of the source code.


Some people are overcomplicating things, insisting on certain features being built-in to any alternative, just because the VCS they are familiar with is built that way.
 
The following users thanked this post: rsjsouza, newbrain, DiTBho

Online voltsandjolts

  • Supporter
  • ****
  • Posts: 3862
  • Country: gb
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #148 on: August 15, 2021, 08:20:19 am »
This is not a great thread for recruiting people to using VCS ;) which is what everybody is telling me I should be doing.

It confirms the very reasons I have been avoiding it. Sole coder, working alone except for defined "plug-in" tasks, and needing regular backups of the repo so why not just do regular backups of the project?

Presumably by this point you have made the effort to do a bit of reading or watching tutorial videos, and installed a VCS to try it out?
So, perhaps now would be a good time to ask more specific questions about things your stuck with?
 

Offline thinkfat

  • Supporter
  • ****
  • Posts: 2163
  • Country: de
  • This is just a hobby I spend too much time on.
    • Matthias' Hackerstübchen
Re: A version control system for embedded work, which doesn't need a PhD
« Reply #149 on: August 15, 2021, 09:00:08 am »
In this day and age there is really no need to bother with a VCS that doesn't support change sets. You'll learn that once you try to roll back changes that span multiple files with CVS or RCS.
Everybody likes gadgets. Until they try to make them.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

- - -
-->