-
Currently I do an automatic daily backup at 3am, plus occassional (3-4 times a day) backups which are preserved separately, and of the entire Cube IDE project directory.
Apart from the Cube IDE application config (under c:\st\.... \Configuration) which I also backup sometimes, and the Cube IDE installation itself (under Program Files) that is the entire project.
Various people tell me this is a crap approach and I should use proper version control. I know basically what it is (many years ago I used PVCS) but need something simple which I can understand.
So I did a google. And I see a ton of garbage, like this https://www.newelectronics.co.uk/electronics-technology/version-control-for-embedded-software-engineers/155521/ (https://www.newelectronics.co.uk/electronics-technology/version-control-for-embedded-software-engineers/155521/) where it claims
The IoT is at risk of taking us back 30 years to the time when network stacks were being built without inherent security measures in place, therefore risking, for instance, massive DDOS attacks.
which is BS. A DDOS attack is not going to happen just because you have poor security. It will happen because somebody doesn't like you, and wants to saturate your internet connection :) And if you have bad security you don't need a DOS attack to break in. So when I read something like that, the rest of the article is likely to be BS also.
There there is BS like this: https://www.embeddedcomputing.com/application/industrial/7-steps-to-choosing-a-version-control-system (https://www.embeddedcomputing.com/application/industrial/7-steps-to-choosing-a-version-control-system)
Git is said to be popular but looks incredibly complex. I've been programming since about 1980 but my eyes glaze over when I read this :)
My recollection of VCS is that you are basically replacing one backup location, which can get trashed if the machine blows up (so you keep copies in different places), with another backup location (which can get trashed, and is actually more likely to get trashed because you are storing the original plus a load of diffs, so to get back to version x you need to unwind y diffs, and if there is any data corruption, you have a disaster because the whole structure is binary and you just end up with a mess. This actually happened with PVCS; people got trashed backups. It's the same issue with differential backups (regardless of the media used) which (in general) nobody uses for anything critical IF they can back up the whole project every time.
The VCS archive needs to be stored somewhere and that will be the ultimate weak point. So you now need to back that up as well, and keep different versions :)
How do people solve this?
-
There are a plethora of methods...
Mostly they are really UNIX methods..
just because .. you know.. MS is a BS GUI shit.
RCS is the most competent method for pontual control
** IT DOES RUN ABSOLUTE FINE UNDER CYGWIN **
as most POSIX compliant tools - but you know.. MS will never support CYGWIN
http://www.cs.purdue.edu/homes/trinkle/RCS/ (http://www.cs.purdue.edu/homes/trinkle/RCS/)
Alternative CVS predates GIT and IMHO is simpler.
it does the puddin
http://www.cvshome.org/ (http://www.cvshome.org/)
Anything site wide with timely pontual relies on RSYNC
the defacto daily hourly fast backup
Paul
-
Yes... SVN stands aupar with CVS both predates GIT
and are less powerful but simpler alternatives for branch revisions
Paul
-
I use Cygwin and Rsync; have done for many years.
I did read the description of Git starting here https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F but anything which needs a "book" is out of the question :)
-
You don't have to use it all, though. Much of git's strength is it's ability to do useful merges when multiple people are working on the same code. It's quite likely this is never the case for you, and you can use it as backup and version-keeper by learning only about 3 commands (add, commit, pull).
If you need more, learn that part only when you need it.
-
As I already talked about earlier, I do use Mercurial for this, when using git is not a requirement.
Mercurial definitely ticks all those boxes. It's much simpler to use than git, yet it's also a distributed system, so you can use it locally with no server. Some will say it's less powerful than git, but you're much less likely to shoot yourself in the foot with it. Just my 2 cents.
-
One thing I have realised, after a few near-disasters with Cube IDE, is that there needs to be a feature where you can state that a whole directory must always be backed up whole, for mutual consistency.
For example when working on Cube, you need to backup the project, and you need to backup the Cube config which is e.g.
C:\ST\STM32CubeIDE_1.4.0\STM32CubeIDE\configuration
and there is ~10MB of files there
(https://peter-ftp.co.uk/screenshots/202108064012643218.jpg)
Mercurial looks like a command line tool. That's ok.
AFAICT all these write stuff into the header of every text file, detailing changes, using a text string which you enter just once for that backup. That is quite useful because while I insert a change log into source files, sometimes I forget.
Multiple workers makes things much more complicated but I am not doing that normally. If I work with someone, they will be doing a quite specific portion of a project.
-
I assume you run Windows or Linux?
In that case I can advise SVN tortoise.
It is a shell and fully integrated with windows such that for instance when you look at a folder in Windows explorer a red flag or green V symbol on the folder icon and all the maintained file icons will immediately tell you what files changed and which not.
It is very easy to learn (2 hours tops) but indeed you need to store an archive called repository somewhere preferrably not on the same computer but for instance a NAS.
Then you can checkout the repository on any computer you want or twice on the same computer if you want.
Comparing is easy although I prefer a $25 once a lifetime special tool from scootersoft called Bcompare for this, and you can with checkin automatically update/change some header info (you need to add some specialcharacters) so you can see the date time and version of a file without theneed tose svn.
Many options but try it out or watch a demo. Once used to version control you don’t want to go without.
-
There are a plethora of methods...
Alternative CVS predates GIT and IMHO is simpler.
it does the puddin
Uh, please no. I know you have issues with a lot of modern things but there is really no reason in this day and age to use CVS. You are really giving out strongly opinionated advices that are both terrible and in this case could directly lead to a data loss.
Just one example CVS problem out of many - it will happily commit half of the changes in your working directory and then barf because it has discovered a merge conflict. And now you have half of your changes committed on the server (where someone else can fetch it and start working on it already!) and half not. Yay!
CVS also loves to corrupt the individual RCS files on the server - had to fix those manually using a text editor more than once back in the day. Really really not a system that you can and should use for actually safeguarding your work today.
It was a step forward compared to SCCS and RCS back in the early 90s but it should be left in the grave today. The last stable release was in 2008, that should tell you something about how maintained (e.g. for security vulnerabilities) it is.
If you really hate git for whatever reason, use at least Subversion (SVN). It fixes both the lack of atomic commits (the entire commit either passes or fails, it is never partial as can happen with CVS which operates file-by-file), the repository is much more stable than anything CVS ever had and merging is more sane. And it is actually still maintained.
-
You don't have to use it all, though. Much of git's strength is it's ability to do useful merges when multiple people are working on the same code. It's quite likely this is never the case for you, and you can use it as backup and version-keeper by learning only about 3 commands (add, commit, pull).
If you need more, learn that part only when you need it.
Came here to say basically this (well, with the addition of "push").
For a simple use case with only one developer (you), git provides a relatively smooth on-ramp and you can ignore 97% of the features.
Combine this with a (free) github.com account, you can do offsite backups of the git repository to your github account and not worry about losing all your code in the event of loss/breakage of your local workstation.
-
There are a plethora of methods...
Alternative CVS predates GIT and IMHO is simpler.
it does the puddin
Uh, please no. I know you have issues with a lot of modern things but there is really no reason in this day and age to use CVS. You are really giving out strongly opinionated advices that are both terrible and in this case could directly lead to a data loss.
..
Never had a single issue with CVS SVN or RCS. I have used them extensively over 90s 00s.. but GIT had tookover all relevant issues
Nevertheless they are simpler
RCS is really the tool which GIT can not replace.
But i manage my systems myself so LIBC and compilers are carefully controlled reason why i should had better results
Paul
-
RCS is pretty straightforward, and still useful (IMO) for single-person, local, use. I rather like having to explicitly "check out" files before you can modify them (which seems to have gone out of style.)
But git is a lot more popular, has more tutorials, interfaces to places like github, is supported by IDEs and GUIs, and so on.
Almost every VCS is "very complex" if you want to use all of its features, but the subset that most people need to do useful work is much smaller and more manageable.
Note that VCS and "backups" are not really the same thing at all...
-
Never had a single issue with CVS SVN or RCS. I have used them extensively over 90s 00s.. but GIT had tookover all relevant issues
Consider yourself lucky. There are plenty of well documented warts and problems with CVS/RCS that would easily cause data loss or hard to recover from situations. Plus using it on large repositories with a lot of binary files (e.g. imported vendor binary blobs) is a huge, slow pain.
Nevertheless they are simpler
RCS is really the tool which GIT can not replace.
Of course. RCS is a design from mid-80s so no wonder it is simpler and GIT is not designed to replace a versioning of a single file by a single user. Which is all that RCS does and which you really rarely need when working on a code or PCB project, as opposed to e.g. managing a bunch of independent configuration files (but even for that there are better solutions these days).
But i manage my systems myself so LIBC and compilers are carefully controlled reason why i should had better results
No, you just got lucky and likely use the system in only an extremely basic manner where you didn't hit any of those issues.
Those are problems inherent in the design of CVS/RCS and nothing to do with libc or compilers. If you get a commit broken up because of a missed merge conflict (or a locked/corrupted file or some server-side problem), your can hack around on libc and your compiler as much as you want and it won't help you any.
It is not some kind of bug, it is the direct consequence of CVS having no idea of a "commit" (or "change set") but only acting as a frontend to RCS over the individual files where it commits each file separately with the same message. It is pretty big pain and a difficult situation to recover from, especially on a large project. There is a reason why you won't find anyone except some old legacy GNU stuff using CVS today.
-
Almost every VCS is "very complex" if you want to use all of its features, but the subset that most people need to do useful work is much smaller and more manageable.
^^ This.
I would recommend to go with GIT purely because its mainstream and there is lots of help available. Start by watching you-tube videos about GIT, great resource there.
If you want a GUI and your running Windows or Mac I would recommend trying Sourcetree https://www.sourcetreeapp.com/ (https://www.sourcetreeapp.com/)
-
.
-
So is the TortoiseGIT also a shell around GIT just as TortoiseSVN is for SVN?
Then I also might switch to it, is there to your knowledge a way to migrate from SVN to GIT only to preserve the many years of logging , which I often use to see when a certain change was made and the logging for the reason ?
-
Just use git. It's the most popular for a reason. You don't need to use all fancy features. It's not the easiest thing available but easy enough. If you can write embedded code that works, you can learn git in a few hours during actual work.
I didn't initially like it and I still don't think it's the best thing since sliced bread but it's widely known and does the trick just fine. It takes a few hours to get started but learning curve is still negligible.
Just say no to CVS or SVN. Especially in small projects the requirement of having a server is an issue.
-
There is:
https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git
I had poor results from TortoiseSVN, mostly relating to how slow it was in our large repository (probably made worse by anti-virus), but both of those are just wrappers around the underlying revision control operations, so if it works for you, it will work with git as well. (Git was designed from early on to have a backend set of functions [plumbing] and multiple front ends [porcelain].)
-
.
-
Thanks looks familiar.
Yes, but keep in mind that the Git approach is not the same as the SubVersioN approach, so the menus are different. See below (left TortoiseSVN, right TortoiseGit).
I figured as much seems logical but thanks for the warning.
-
Git + backups
don't underestimate backups!
-
As I already talked about earlier, I do use Mercurial for this, when using git is not a requirement.
Mercurial definitely ticks all those boxes. It's much simpler to use than git, yet it's also a distributed system, so you can use it locally with no server. Some will say it's less powerful than git, but you're much less likely to shoot yourself in the foot with it. Just my 2 cents.
git is perfectly simple. You only need about five commands. You don't need lots of fancy options on the commands. You can always use a sequence of two or three simple commands instead.
You can't shoot yourself in the foot with git if you refrain from using "force" options on commands to make git do things that a VCS should not let you do. The job of VCS is to preserve the history of the project. You committed the wrong thing? That's unfortunate, but now it's part of the history. Commit the right thing and be more careful next time.
-
At a previous company we used VCS and then PVCS. It was OK but a real drag to revert to a snapshot of the system - somehow you'd need to know it's this version of that file, that version of this file, etc. We solved that by applying a label across all files when we did a release (or just because), but per file versioning wasn't the way to go.
After some travels, paying for a quite reasonable system that's no longer appropriate or available, I settled on Subversion. Unlike xVCS it versions a project in its entirety, which is far more sensible. Subversion also comes, with the aforementioned in the thread, TortoiseSVN Windows client, which makes the whole thing very simple and easy to use. No remember arcane command lines, batch files, whatever - it's all embedded in your file manager (and hopefully you use a decent one, like DOpus, rather than Explorer, but it doesn't matter - TortoiseSVN integrates with them all).
World+dog has gone git mad, and any random hip developer will insist git is the only proper way to go now. Git is good for what it was designed for, which isn't what many of us are doing. There is a TortoiseGIT client for Windows (this stuff is what keeps Windows relevant for development IMO) but it's still git and easy to screw up in many weird ways.
Subversion scores for me because it has a master repo (you can have mirrors and change where the master is, but it's a star topology). Where you do stuff is just a checked-out copy that has no bearing until you check it back in. Practically, that means you can do silly stuff which affects the core of the versioning (like merging with completely inappropriate options) and end up with a completely trashed and worthless copy. No problem: just delete it, check out another and try again. I usually have several copies of the same thing checked out - one might be for trying stuff on, and another the real working copy. None of them are important and I can delete them as and when I like.
It really is difficult to screw up subversion. Even if you willfully break things and then check it all in so the repo is polluted, you can just go back to the previous revision and bypass the mess you snuck in there. I think you need to actually delete the repo to score a hit.
With git, you can't do that so easily. The working copy is THE authoritative repo and if you vape the folder you will lose the lot. Sure, you can make copies and all that but keeping track of what's where can be a hassle. I usually have a master repo and then push stuff to that at every check-in so it acts like the master repo. But essentially it is forcing a square git into a round process.
Git does have advantages when it comes to branches and merging, although it's not as foolproof as the walk-throughs and how-tos make it look. For a single developer used to backups as version control, it is way over the top and more likely to put you off than solve anything.
For subversion, I keep the repos on a NAS. The NAS is backed up every day en bloc and things like the repos folder(s) are separately backed up to alternative media. There is no problem having the repos on your main PC and having those backed up as anything else would be. Having them off-PC doesn't really protect against ransomware unless you keep them offline when not actively accessing them, but offline backups are a step in the right direction (although not infallible).
-
It really is difficult to screw up subversion. Even if you willfully break things and then check it all in so the repo is polluted, you can just go back to the previous revision and bypass the mess you snuck in there. I think you need to actually delete the repo to score a hit.
With git, you can't do that so easily. The working copy is THE authoritative repo and if you vape the folder you will lose the lot. Sure, you can make copies and all that but keeping track of what's where can be a hassle. I usually have a master repo and then push stuff to that at every check-in so it acts like the master repo. But essentially it is forcing a square git into a round process.
This is just ... completely mistaken.
You're psyching yourself out.
-
I found this site useful for understanding why git is designed the way it is:
http://think-like-a-git.net/ (http://think-like-a-git.net/)
-
This is just ... completely mistaken.
You're psyching yourself out.
Well, if you have only one copy of the repo and nuke .git with some bad invocation of rm then you are legitimately screwed indeed ;)
Subversion kinda protects you by not being able to work that way at all.
I would still use git.
-
Uh... why turn this thread into a VCS flame war? It looks like git proponents tend to be fanboys sometimes. Calm down guys. Git is fine but has its shortcomings, and is relatively complex to grasp for users not familiar with VCS. Yes it can be used in a simple way with no risk if you restrict it to a small subset of commands, but then it's a bit like the whole C++ debate (like "C++ is fantastic is you don't use this and that feature, use a subset").
So suggesting something else is alright. The OP will then make its choice freely. Having options is a good thing.
-
Last generation only know Git, that is also what they are being taught at school, and it is a very good vcs so I can understand why they advise it.
-
CVS was used for many years in my company without any of the issues mentioned here and it was replaced by the new kid on the block (Git) simply due to its discontinuation of support (last stable was in '08 or '09 IIRC). Did we have luck? Perhaps, but it was used by hundreds of developers across different sites, so I think it would be "lottery-winning" level of luck.
In any case, either SVN or GIT should work.
SVN is a bit loose when defining Tags and Branches and Git can be a bit dense, but for a single user in a contained environment both should work quite nicely.
-
If your application resembles the Linux kernel, where your role is to integrate pull requests from hundreds of contributors all over the world, then Git may be the best VCS for you. That's literally what it was designed for.
Otherwise, Git probably isn't the best VCS for you, but you'll probably end up being browbeaten into using it anyway, just because "It's what all the cool kids are doing."
For individual use, Perforce works especially well. It's free for single-user installations.
-
"For a single developer used to backups as version control, it is way over the top and more likely to put you off than solve anything."
That is exactly where I am, and have been for many years.
-
We use Git at work, I don't find it to be particularly difficult to use. There are about 5 commands that I use all the time and once I learned those commands I haven't had any trouble with it. I have not tried administering a Git repository though so I don't know how complicated it is to set it up.
-
You could try svn and git and see which suits you. You never know - you might be a git person at heart :)
Being Windows based a GUI would be of big benefit. There are a few around but I would nearly always go for a Tortoise client if it's available, simply because they are robust, well proven and intergrate into the OS. You can have them all installed together since they don't interfere with each other (or anything else).
TortoiseSVN (https://tortoisesvn.net)
TortoiseGIT (https://tortoisegit.org)
One of the hurdles to get going is having to create a project, create the repo, check in, do mode, check in, etc. But fortunately a zillion developers have given you a shortcut via github. Just go to a likely github project and checkout the source. Despite the name, github also provides svn access so you can get the same thing in the different clients for comparison.
Well, almost. Naturally, git and github are ideal for what they do there, whereas svn isn't. The upshot is that when you check out with git you download the repo as well, so repo access is very fast (unless you need to refer back to the github repo (aka the origin). With svn the repo stays at github, so any repo access (viewing the log or revision graph, for instance) involves a slow webdav transaction. Nevertheless, if you bear that in mind if gives you a good flavour.
Oh, also, if you pull the git version using the URL github supplies, you get a version of the code (plus the repo). If you do that with svn you get the entire repo contents (that is, all the branches and tags as well as the trunk), which probably isn't what you wanted. So with svn, do a repo browse to select what you want to pull down.
Edit: if you do get samples off github, bear in mind that checking any mods in will want to push them to github, which might be embarrassing. With git the changes will stay local unless you push to the origin so you should be safe, but I'd still not want to make a change and practise checking it in to someone elses live project... probably best to treat them as read only.
-
Git is fine but has its shortcomings, and is relatively complex to grasp for users not familiar with VCS.
I think the problem is more with the people who *are* familiar with another VCS, rather than the beginners.
-
Last generation only know Git, that is also what they are being taught at school, and it is a very good vcs so I can understand why they advise it.
Whereas I have used (at least): SCCS, RCS, CVS, SVN, PVCS, Visual SourceSafe, Projector, Mercurial, Perforce ... and git.
Mercurial is a bit of a toss-up on features, but git wins by far on ecosystem. The rest -- I'm never going back. You can't make me.
I'm especially not ever going back to anything that requires a team member to get an exclusive lock on a file before they can make even experimental or temporary changes to it.
Perforce has one useful feature of being able to map portions of a vast corporate repository into your workspace, but is otherwise an abomination.
-
Whereas I have used (at least): SCCS, RCS, CVS, SVN, PVCS, Visual SourceSafe, Projector, Mercurial, Perforce ... and git.
That brings back memories, I also was the "victim" of some of those.
The worst IME was IBMs Clear Case, oh man that was cold war thinking stuff where you need tons of permissions, grants and so on before you coukd change one line :palm:
-
Git is like make, it's not perfect for every task but is easy enough, and widely used enough, so people just learn some subset and get on with their lives, to do the actual work.
Comparison to C++ is invalid because working with the programming language is the actual work, while version control is just a tiny auxiliary task (which is there to save time) and if it is taking any significant time then something is definitely wrong. Fanboys of course can dedicate their lives on managing the VCS. But today git's so widely used that true fanboys are 0.01%.
Hence, for a software project, you absolutely must understand how to use the programming language of choice, and the subset can't be small. But a more limited experience in the VCS can be acceptable to just get that part of job done.
-
The worst IME was IBMs Clear Case
STOP! You're triggering me!
Sigh.
-
First of all you should never mix up backup strategy vs. version control. A version control system is no backup, if you remove the repository by accident, be it on the same computer or on a different one, you are fucked up if you have no backup. If you have a backup of your project, you do not have a version control. So be prepared to have a version control system *AND* a scheduled backup of your repository/work.
Having used several VCS, we migrated from CVS to SVN in the past. Now I am migrating our software development to git. For my personal stuff I moved to git years ago, in the company I struggled with several organisational aspects (one being the NIH-syndrom).
Don't be fooled by statements that SVN is protecting you against removing your repository by accident: if you are using a repository on your hard disk, you have the exact same situation as with git. If you have a remote repository, you cannot work stand alone with SVN. With git you can have both.
Bernd
-
if you are using a repository on your hard disk, you have the exact same situation as with git.
This is wrong.
To lose the subversion repo you need to delete the repo. Nothing you can do where you're actually using the data can zap the repo.
To lose the git repo you delete the working directory. Hopefully you will have pulled it from some upstream place, so you can re-pull it, but if you haven't pushed changes upstream as well as checked them in locally they are toast.
-
You mean that by default git stores the objects in .git subdirectory of the working directory. If this is what you mean, then yeah, a recursive removal of the working directory and all subdirectories including those starting with ., yes, it's gone.
Of course it's highly recommended to have some upstream where to push, preferably accessable from the interwebz. Like github or similar, very easy to set up. This enables you to continue working elsewhere as well.
-
If you have a remote repository, you cannot work stand alone
This is also not quite true. You can use svnsync to mirror the remote locally (or not-so-remotely as the case may be).
To be more precise, I think you mean you can work unintentionally offline with git (but, of course, then hit the single point of failure issue and delete everything).
-
If this is what you mean, then yeah, a recursive removal of the working directory and all subdirectories including those starting with ., yes, it's gone.
That's what I do regularly. I'll be working on something in R:\project\working and have a bright idea or want to test something so create R:\project\temp. Do stuff, don't need it any more, erase ~\temp. With subversion any changes I checked in I can then pull into ~\working. With git they are gone unless I pushed them to ~\working after checking them in. And before deleting them, obvs.
Now, admittedly, I haven't done that since the second time I accidentally did it, but I am forever fearful of exactly what I am deleting when I vape no longer required working folders. OTOH, I don't want a load of empty, except for .git, folders littering my storage. With svn I just don't give it a second thought because there is nothing critical anywhere an editor or delete command is going to be used. The worst I can do is check in some absolute rubbish that will be preserved for posterity.
Now, you may think that a workman likes sharp tools. Indeed, that is a generally safe view, but OTOH I don't use a slot drill to make a hole.
I am not suggesting git is rubbish - it is excellent at what it was designed for. But a single developer not collaborating with world+dog, wanting a simple tool, was not Linus' target.
-
.
-
To lose the git repo you delete the working directory. Hopefully you will have pulled it from some upstream place, so you can re-pull it, but if you haven't pushed changes upstream as well as checked them in locally they are toast.
If this is seriously a problem for you, then do..
Once:
sudo mkdir /opt/git
sudo chown $USER /opt/git
(or anywhere else you want)
And then for each new project:
git init --separate-git-dir=/opt/git/foo foo
cd foo
Or create a bare repo somewhere on your local filesystem or network, add it as a remote, and then push to it from time to time, obviously.
-
https://git-scm.com/docs/git-worktree
I also used to symlink .git to multiple workdirs long before this option became available, but it had the downside that the current branch must be changed each time you move to a different checkout and you have to be careful not to overwrite files by accident.
edit
For a complete subversion experience, you could (presumably?) keep --bare repositories somewhere in one place and as many checkouts as you want elsewhere. Then you know that each workdir can be nuked at any time and only uncommitted changes are lost.
-
How do people solve this?
Many words been said about Git and easy to follow 'do just as we do' ::)
Gladly, there is another alternative - all-in standalone minimalistic DVCS with build-in extras that works well on Windows, macOS, Linux (Ubuntu,SUSE) and FreeBSD :)
https://www.fossil-scm.org/home/doc/trunk/www/index.wiki (https://www.fossil-scm.org/home/doc/trunk/www/index.wiki)
2.0 Differences Between Fossil And Git
https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki (https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki)
-
Or create a bare repo somewhere on your local filesystem or network, add it as a remote, and then push to it from time to time, obviously.
That is what I do, but push to it every time. Obviously. And that allows it to get backed up properly too. But since that's exactly how and why I use svn, I'm wondering why this is better when it takes more steps, leaves more debris and isn't the way it's meant to be used.
-
The worst IME was IBMs Clear Case, oh man that was cold war thinking stuff where you need tons of permissions, grants and so on before you coukd change one line :palm:
Damn, I though I had recovered from that experience and mostly removed that abomination from my memories, but I still shiver reading about it.
I still remember that in any project, even smallish ones, we needed more or less one FTE configuration manger as a human sacrifice to placate that ghastly beast.
Also their firstborn or spouse, if one more branch was needed.
-
More 2 cents...
Apart the chosen method... not surprisingly PERL can put a common abstract layer easily on every one of them...
- https://metacpan.org/pod/Rcs
- https://metacpan.org/pod/Cvs
- https://metacpan.org/pod/SVN::S4
- https://metacpan.org/pod/Git
PERL has been my preferred method for abstract interfacing any of them...
you know.. things change over time and it is very good keep sanity
Paul
-
That's what I do regularly. I'll be working on something in R:\project\working and have a bright idea or want to test something so create R:\project\temp.
But, allow me to say, if you are using this strategy with git "you are holding it wrong".
The easiest way is to create a new branch from where you are, and use it for your tests and experimentation.
The mantra with git is "branching is cheap".
If you are happy with the results, the experimental branch can be easily merged back into the main one.
If not, it's enough to checkout again the main one, then you can delete it - but it's often better to keep it around (maybe there was some good idea).
If you are only partly happy there are a number of alternatives, depending on the cases: cherry pick the commits you like into the main branch, pick just some files etc.
If in the time you work on your idea the main branch has progressed, you can merge it every now and then to keep current, or rebase on it (with some caveats).
PERL has been my preferred method for abstract interfacing any of them...
you know.. things change over time and it is very good keep sanity
PERL and sanity, what a strange combination :-DD.
-
Or create a bare repo somewhere on your local filesystem or network, add it as a remote, and then push to it from time to time, obviously.
That is what I do, but push to it every time. Obviously. And that allows it to get backed up properly too. But since that's exactly how and why I use svn, I'm wondering why this is better when it takes more steps, leaves more debris and isn't the way it's meant to be used.
If you push to it every time then do it the way I showed, with repo and checkout in different places.
-
PERL has been my preferred method for abstract interfacing any of them...
you know.. things change over time and it is very good keep sanity
PERL and sanity, what a strange combination :-DD.
Yep... took me awhile (circa early 90s start dealing w/PERL..)...
But after a steep initial crank ... make no mistake about PERL.
It is currently the most powerful and wise method to achieve from simple to complex tasks close *very close* to a POSIX OS. Fast absolutely concise and way smarter than above others..
Frequently you find talks about replacing POSIX shells w/PERL.
Benefits of having OO integrated binding to TCL/Gtk/Qt and almost any wrapper you can think of already in CPAN.
Still today I wonder how damn smart is PERL above other alternatives
A COMPILER frequently kicks in discussion.. (OR JIT) but that will just make things worse as you can manage a perl site way smarter without such things..
It takes time to manage. I am not even close the masters ..
Frequently I wonder how damn powerful some things can be easily done in it.
Paul
-
That's what I do regularly. I'll be working on something in R:\project\working and have a bright idea or want to test something so create R:\project\temp.
But, allow me to say, if you are using this strategy with git "you are holding it wrong".
The easiest way is to create a new branch from where you are, and use it for your tests and experimentation.
The mantra with git is "branching is cheap".
Branch switching is fun until you want to work on multiple branches simultaneously for a prolonged time and perhaps even have many of them opened in the editor at the same time. Constant recompilation of all the files that differ between branches isn't fun either.
-
Branch switching is fun until you want to work on multiple branches simultaneously for a prolonged time and perhaps even have many of them opened in the editor at the same time. Constant recompilation of all the files that differ between branches isn't fun either.
What the frog do you have to version?
and how do you resolve merge conflicts in a Git repository?
-
Clearcase was indeed brutal.
-
What the frog do you have to version?
and how do you resolve merge conflicts in a Git repository?
Well, any project which keeps stable release branches around and supports them with bug fixes. As the old releases diverge from master it can become quite tedious to switch branches and recompile everything to chase an old bug. Bonus if there is urgent work on master to do at the same time.
Or maybe you work with something like gerrit where features are developed on side branches, reviewed and then merged to master. The features may be independent so there are no merge conflicts, or they may be interdependent and then the developers need to coordinate. At any rate, if you participate in the development of several features, you want several branches and this is more convenient to manage with several checkouts.
Or perhaps you have a few versions of Linux-the-kernel to maintain and deploy on various systems. You want separate build directory for each one because stable releases only receive small fixes most of the time and incremental build saves time. But you want to share .git between them because the thing has grown to a few gigs in size nowadays.
-
But, allow me to say, if you are using this strategy with git "you are holding it wrong".
Feel free, and you are right :)
The easiest way is to create a new branch from where you are, and use it for your tests and experimentation.
The mantra with git is "branching is cheap".
Yes, the new one might well be a branch (or might not - depends on circumstance). But that doesn't change anything: I will have multiple working folders and most, if not all, of them will be vaped at some point.
Yes, I could keep checking in and out to the same working folder, but for various reasons I will drop in and out of editing/viewing/breaking them, sometimes on a whim. I might use one purely as a reference if it's a big project. And, of course, there are times when I am supremely lazy and the hassle of having to tidy up the current stuff, check in, out, view, check out, let the editor figure out it's symbols table is skewiff... nah, can't be arsed this time.
Contrast all that with a massive and lengthy file.. open.. MRU pick. Or even just alt-tab because with multiple directories I can have multiple editor instances at the same time. Strangely, that seems to be news to some developers!
-
If you push to it every time then do it the way I showed, with repo and checkout in different places.
Sorry, I overlooked the critical detail of that one.
Edit: mostly because I can't seem to get it to happen on Windows.
-
If you push to it every time then do it the way I showed, with repo and checkout in different places.
Sorry, I overlooked the critical detail of that one.
Edit: mostly because I can't seem to get it to happen on Windows.
I have no idea why, because that specifically uses a text file (called ".git") in your project directory that contains the path of the actual git repo in plain text. There is no use of symlinks or hard links or other Unix-isms.
-
Other than working on Wind0ze, it's no better than symlinking. You still end up sharing one HEAD state, which means that changing branch in one working directory changes it for all the others too ::)
-
Other than working on Wind0ze, it's no better than symlinking. You still end up sharing one HEAD state, which means that changing branch in one working directory changes it for all the others too ::)
The threat model he was concerned about was rm -rf'ing the source code checkout directory and losing all history.
If you want multiple checkouts then you make a master repo somewhere (which you probably want to be "bare" i.e. without a source code checkout) and use git clone to make each working directory. If the master repo is on the same filesystem then the working directory copies will hard link to the master repo rather than duplicating all the data.
-
The notable point is that while a VCS enables you to do all sorts of clever stuff e.g. go back to version current minus x to see where you broke something (which is a great thing to have) it doesn't get around the need to back "something" up whole, and to that regularly.
All that changes is that instead of backing up the project, and the IDE app (in this case ST Cube IDE) configuration (which is likely spread all around the place; in this case in c:\st\...\Configuration) and doing this at each significant point in the development, you now have to do the same thing with the VCS repository.
The repo needs to be copied (but not automatically mirrored, for obvious reasons) to another piece of hardware. My experience is that no matter what quality parts you use to build a machine (and I have built many more than I could remember) what tends to happen is that the power supply blows up and takes out not just the motherboard but the HD, and the HD controller. When I build a machine I buy two motherboards for this reason, but have stopped using RAID because both HDs tend to go, or just the controller goes and unless you can get an identical RAID controller you have lost all the data anyway.
So, as with so many things in "IT" e.g. "cloud storage" all you are doing is moving the "backup policy" from one place to another.
-
The threat model he was concerned about was rm -rf'ing the source code checkout directory
... while deleting the checkouts of abandoned branches.
If you want multiple checkouts then you make a master repo somewhere (which you probably want to be "bare" i.e. without a source code checkout) and use git clone to make each working directory. If the master repo is on the same filesystem then the working directory copies will hard link to the master repo rather than duplicating all the data.
I suppose it will stay that way till the first background run of the repacker in either repository ;)
And won't apply to subsequent fetches from other remotes.
-
Don't think it has been mentioned so thought I would: https://www.fossil-scm.org/ (https://www.fossil-scm.org/)
-
Don't think it has been mentioned so thought I would: https://www.fossil-scm.org/ (https://www.fossil-scm.org/)
It was, some posts above:
https://www.fossil-scm.org/home/doc/trunk/www/index.wiki (https://www.fossil-scm.org/home/doc/trunk/www/index.wiki)
The concept and philosophy behind it might be interesting (though their "git vs. fossil" page is really biased*), but there's a fundamental objection to this SCM, and to all non-git ones:
Stackoverflow survey 2021 (https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-other-tools).
I don't think this to be a case of "million of flies" - these are people who use tools for productive work, both independent workers or enterprise employees.
Possibly an exception could be made for mercurial or subversion, but in my personal experience, their user bases are also shrinking.
E.g: for work, I was recently involved in the migration of a (quite niche) FOSS from mercurial to git.
It went really smoothly, and both users and devs were happier in the end.
There was some internal initial resistance to the move from a couple of developers, mostly due to adapting to slightly different way of working, but nothing major.
One of them, in fact, was then tasked with laying out the new way of working with git (branching, tagging, and merging strategies) - and they made an excellent job.
* But they admit it. In Italy we say "oste, è buono il vino?" ("innkeeper, is your wine good?"), what answer do you expect?
-
* But they admit it. In Italy we say "oste, è buono il vino?" ("innkeeper, is your wine good?"), what answer do you expect?
Absolutely. ;D
-
Git is a horrible version control system -- but I use it all the time. Yeah, something being popular can be a good reason to use it.
I've long been a fan of DVCS but git was the one I didn't want to win -- so of course it did.
- The name "git" is just bad. There is something very wrong with professionals using a version control system named after an insult.
- The command-line interface is confusing and inconsistent. Never feel bad if it is confusing to you.
- It isn't even really a program, it is C code with a bunch of scripts and shell dependencies. Git for Windows is a mess of things hacked together.
- git LFS is a hack.
- Merge history is not preserved. After you merge a branch, you cannot determine which branch changes were done on.
- Garbage collection can and will decide to throw away commits you've done. This only happens if something isn't tagged or branched but a version control system should never throw away history.
-
Git means "ok" or "fine" over here. Americans will always find something to complain about :popcorn:
-
If git was perfect they would have called it god ;)
-
noun British informal an unpleasant or contemptible person: that mean old git | a warped, twisted little git.
– origin 1940s: variant of get (sense 2 of the noun):
British informal or dialect a person whom the speaker dislikes or despises.
-
Speaking of Americans :-DD
hint: Using 'master' as the name for the initial branch. This default branch nam
e
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
The genius who made this commit also apparently tried to format the message so that the lines don't wrap but failed to account for the prefix added by git :clap:
-
Git means "ok" or "fine" over here. Americans will always find something to complain about :popcorn:
Words always have context. Linus Torvalds didn't pick a name that meant "ok" or "fine". That's not his style. It's pretty well documented that he intended the insult. He wanted to name it something stupid. I'm not personally bothered by something like this, but as an engineer, communication matters. Having something childish like this doesn't help when trying to represent the new and growing software field to others who don't understand it.
-
Interestingly, there's something similarly wrong with the "Rust" name for the Rust language.
I agree that communication matters. And actually, as you mentioned, Linus *did* pick the name for a reason. The reason itself does say something about what his intent was. And his intending the insult is sort of reflected in how defensive git proponents usually become when you start criticizing it.
But Linus is well known for this kind of behavior. Don't get me wrong, I think he's a great guy overall and has done a lot of good, but his attitude has always been pretty much offensive and self-centered. The name of "Linux" should give you a hint as well.
Ok we're digressing a bit here, but not so much. Many people seem to agree on the fact git has its flaws, but that they'll still use it because it has become so widely used. The very success of git, compared to other systems that are objectively good as well, is likely due not just to its merits, but to the aggressiveness with which it has been imposed by those deploying it.
-
The name of "Linux" should give you a hint as well.
Regardless of Torvalds' motivations and personality, if I was creating something that I thought was pretty new I would also have found a way to tag my name to it. Besides, his name goes along quite well as an anagram of the master system Unix and very few people can dissociate the product from the name of its creator. Genius!
-
Many people seem to agree on the fact git has its flaws, but that they'll still use it because it has become so widely used. The very success of git, compared to other systems that are objectively good as well, is likely due not just to its merits, but to the aggressiveness with which it has been imposed by those deploying it.
I'm not so convinced.
I never saw much evangelism for git (but that's just me, maybe).
My idea is that git (flawed, as all the others are in a way or another) has spread so much because, in its basic form, you can make do with very few commands, and later add sophistication to your use.
The initial learning curve is not at all steep (it gets worse (https://git-man-page-generator.lokaltog.net/), though).
This allowed it to snowball, and the current picture is that there are tutorials everywhere, all IDEs and editors integrate it in a simple way (well, not Eclipse, of course - but I'm repeating myself) and if one has a question any git on any forum can usually answer.
At this point, it's a self sustaining process: if one is at least a bit into FOSS, they are bound to come in contact with it, and then, why invest time and effort in learning something else, unless really warranted by some special need?
Personally, I don't feel any urge, and, TBH, I'm a bit annoyed when some piece of FOSS I need force me to use something else (so I need to look up syntax and WoW that I'll promptly forget).
-
SiliconWizard is onto something. This was Linus' secret weapon: he made it appeal to gits, and software developers in general are gits. So yes, you will be assimilated >:D
I like git and I think it's the least evil VCS. It's stupidly simple (hint hint) and unlike a lot of software, one can quickly learn how it works and then all else becomes a matter of RTFM on as-needed basis. Yes, the individual commands were designed ad-hoc and sometimes suck, but if you understand what you want to achieve, it's not that hard to find the one that does it. It's a working programmer's VCS and that's how it mostly obliterated the others, particularly those designed for "UX" and "ease for newcomers". (Who gives a damn about those bastards, we want some job security too ::))
Well, maybe hg would make a good VCS for university courses just like many of them teach Pascal instead of C, but one day you graduate and move on :-DD
-
- Merge history is not preserved. After you merge a branch, you cannot determine which branch changes were done on.
- Garbage collection can and will decide to throw away commits you've done. This only happens if something isn't tagged or branched but a version control system should never throw away history.
these two are bad
-
- Merge history is not preserved. After you merge a branch, you cannot determine which branch changes were done on.
- Garbage collection can and will decide to throw away commits you've done. This only happens if something isn't tagged or branched but a version control system should never throw away history.
these two are bad
I don't agree.
The first one simply isn't true. Diff the merge commit with its parents and you see exactly which branch changes came from.
The second is like complaining about the existence of the "Empty Trash" command on Mac or Windows, or /tmp on *nix.
-
Ok we're digressing a bit here, but not so much. Many people seem to agree on the fact git has its flaws, but that they'll still use it because it has become so widely used. The very success of git, compared to other systems that are objectively good as well, is likely due not just to its merits, but to the aggressiveness with which it has been imposed by those deploying it.
I thought that the main reason for git's widespread adoption was because "it's used with the Linux kernel." Hence "if it's good enough for the kernel, then anything else in the FOSS world should use git, too." It's the basic network effect (a real-life tautology) ... everyone uses it because everyone uses it. And nobody will switch to something else because nobody uses anything else.
We use Subversion. We have been using it for a long time. The main (indeed only) company repository is served by a Linux box in a rack in a closet. We came up with a workable repo structure. The repo gets backed up automatically every night. We don't see any compelling reason to switch to git. I mean, I look at git regularly (every vendor now has a GitHub repo for their libraries and such) but for the way we work -- each engineer works on their own projects -- there's nothing offered by git that is a must-have.
Everyone's mileage (kilometer-age) varies, of course. The point is that everyone doing firmware/software development should just pick an SCCS and start using it.
-
SVN was for sure the best VCS in 2004 and I switched employers and a few open source projects from CVS to SVN over the next couple of years.
Where I worked, by mid 2007 other employees were sucking the official SVN repo into git and using that for their feature development and for pushing in-progress stuff to each other, only committing finished things to SVN.
As the SVN-master I resisted for a while, but the writing was on the wall. git was clearly superior in almost every way.
The main sticking point was that a really nice tool called CVSzilla had been developed at my 2002-2004 employer, which integrated CVS (and later SVN) with Bugzilla and ViewCVS (later ViewVC when SVN support was added). CVSzilla added a commit-hook which created atomic transactions in its own database (not needed with SVN) and added a bugzilla comment for each commit, with a URL to browse the commit. That kind of tooling didn't exist for git at the start. I evangelised CVSzilla into my 2004 and 2006-2009 employers as well as open source projects such as Gwydion Dylan.
SVN's reign was about three years. I can't imagine using it for a new project now. It would feel like some kind of perversion.
-
I just stumbled over this in the ACCU's Overload magazine, which seems applicable.
See https://accu.org/journals/overload/29/164/overload164.pdf for the full (free to read) magazine.
-
the ACCU's Overload magazine
Interesting that he says, "the tool is not the problem, the workflow is". To me that's arse about face - we have tools to help us, not get in the way and screw up how we do things.
The obvious road ahead, from that, is competing tools demanding you do stuff their way and stuff the other tools' way. Which to bow down to...
-
- Merge history is not preserved. After you merge a branch, you cannot determine which branch changes were done on.
You got that wrong.
(https://www.eevblog.com/forum/programming/a-version-control-system-for-embedded-work-which-doesnt-need-a-phd/?action=dlattach;attach=1243998)
-
This works because you use sensible merge commit messages. If your message was simply "lol, let's merge dat shit now" then you wouldn't know what the branch was called after you deleted it.
That post probably came from a Mercurial fanboy ;)
-
This works because you use sensible merge commit messages. If your message was simply "lol, let's merge dat shit now" then you wouldn't know what the branch was called after you deleted it.
That post probably came from a Mercurial fanboy ;)
Wrong, on both counts, mr magic.
Sourcetree works with git and mercurial (which I have never used, but read good things about it, perhaps closest competitor to git?)
-
The first one simply isn't true
Ah, the disinformation effect. I don't like it when people spread fake news like that :o
Yesterday I woke up early in the morning, took my road bicycle and went to the lake and spent the day there. Nice plan, but it's 160 km there and back. So I was a little tired when I got home and I opened the tablet to see what was going on here.
I felt a little worried about these two points. Especially the first one made me seriously worried about Git, a field I'm not an expert in, my skill are basics with Git because I tend to use it for basic operations, and usually for single person projects or LaTex documents, and you can guess why ... I tend to avoid merging too many things that might have conflicts, but it happens so I have a bad feeling because the history of merging really needs to be truly preserved.
Thanks for the answer, it averted possible and catastrophic disasters ;D
-
Umm, looking at its dependencies ... I see
- bash-completion
- curl
- mozsha1 or ppcsha1 (opts+=" BLK_SHA1=YesPlease" / opts+=" PPC_SHA1=YesPlease")
- threads
- cpio (why? isn't tar enough?)
- nls
- "-lpcre" (yes, it tries to link this library)
which are somehow fine, but
- perl? for things like HTML-Tree?!? DateTime-Format-ISO8601?!?
- MediaWiki?!?!?
- emacs?
- python? for things like pygtksourceview?!?
- tk?
- svn?
- cvs?
- gnome-keyring?!?
and a lot of patches, Git, at the source level, looks something weird :o :o :o
-
Wrong, on both counts, mr magic.
I'm never wrong. I meant the post which you responded to - that one came from the camp of "omg no edit my histories please" :D
Show how your sourctree helps in this case:
git init x
cd x
git commit --allow-empty -m x
git checkout -b y
git commit --allow-empty -m y
git checkout master
git commit --allow-empty -m z
git merge y -m 'merge dat shit lol'
git branch -d y
Task: figure out what was the name of the branch that commit y came from. Yes, any tool will tell you that it came from some branch merge, but which one?
Mercurial takes care of that, fossil presumably too. I would still use git.
-
- perl? for things like HTML-Tree?!? DateTime-Format-ISO8601?!?
- MediaWiki?!?!?
- emacs?
- python? for things like pygtksourceview?!?
- tk?
- svn?
- cvs?
- gnome-keyring?!?
I would not want o come out as a git fanboy, as to me it's just a tool that happens to be handy and working as expected (for the most part) on all the platforms I use (Linux, Windows, FreeBSD, a little Mac), but:
Most of the above are either for interworking (cvs, svn) or for the graphical client (tk, probably python) or for extensions and APIs (probably perl, emacs, gnome-keyring).
-
I'm never wrong.
Hmm, nice oxymoron.
Show how your sourcetree helps in this case:
I'm lazy, I just use Sourcetree for all my git interactions and it just works.
I'll leave you to sort out your own mess.
-
( @newbrain, yup ... I am doing something really "insane", like distilling the minimal setup to compile Git on my PDA; the family 1.6.* of Git looks the best candidate because it's the one with less patches and less "options" to be manually configured ........ also it's the one when if you disable Perl and Python, it doesn't run any test .... and this saves precious building time; will this minimal configuration be *enough* for my basic needs? let's check it out :D )
-
Wrong, on both counts, mr magic.
I'm never wrong. I meant the post which you responded to - that one came from the camp of "omg no edit my histories please" :D
Show how your sourctree helps in this case:
git init x
cd x
git commit --allow-empty -m x
git checkout -b y
git commit --allow-empty -m y
git checkout master
git commit --allow-empty -m z
git merge y -m 'merge dat shit lol'
git branch -d y
Task: figure out what was the name of the branch that commit y came from. Yes, any tool will tell you that it came from some branch merge, but which one?
Mercurial takes care of that, fossil presumably too. I would still use git.
"figure out what was the name of the branch"
Of what possible relevance is that? The name can be changed at any time. Hell -- I can make some chained commits and then merge them without ever making a named branch.
It's the contents of the commits that matter.
-
It's the contents of the commits that matter.
To a point. Knowing that the commit fixes some specific bug or implements some specific feature is perhaps as important when going through history. You might be trying to determine if this version has that fix, and knowing that some weirdo code has changed to some other weirdo form doesn't help that along much.
-
I just use Sourcetree
Any idea why you need an account at Atlassian to use Sourcetree? Can they decide not to let you use it (and stop it working), get telemetry or whatever from it? Do you have to be online for it to work?
-
even mercurial has interesting dependencies
- chg -> support mercurial command server/client (is it mandatory?!?)
- emacs
- gpg (why?!?)
- tk (for what ?!?)
- zsh-completion
- python (for what?!?)
this is also interesting:
If you want to convert repositories from other tools using convert extension please install correct tool
- cvs
- darcs
- git
- monotone
- subversion
darcs?!? monotone?!? never heard about
-
Any idea why you need an account at Atlassian to use Sourcetree?
Atlassian own Sourcetree and they provide it free of charge, but they would like you to use their services (bitbucket), so it's their way of pulling you in.
After initial setup you are free to use any repo service or your own.
Bitbucket service works fine but the web interface isn't nearly as good as github.
Can they decide not to let you use it (and stop it working), get telemetry or whatever from it?
Probably. Maybe they could lock it to bitbucket someday, if they were willing to piss off customers. Regards telemetry, I don't know.
Do you have to be online for it to work?
No
-
Thanks :)
Shit program, though. Installs to Appdata without asking or warning, and when uninstalled doesn't actually remove any of the shit that it's filled the system with.
-
That topic got deep, fast :).
I'll toss my opinion in the ring for Git as a simple backup-of-my-work repository. Once you've created a new Git repo all you'll be doing is commit of the current branch to the repo for backup purposes.
Although you probably want to verify you're using the correct commands it's really only a single one to back up the entire working directory to the repository you've created. And then a single command should you ever need to restore that (current version) backup to a different system.
Just use it as a simple fire-and-forget backup that could possibly be automated. For which Git (in my opinion and similar use case) works brilliantly. You'll get the versioning added for no additional effort.
You can always figure out reverting to Mondays commit later if it ever comes up as desirable.
And if you want *really* simple, rsync to a datestamped directory on some backup medium, local network, or cloud service. No inherent versioning but it doesn't get much simpler.
-
If you use git like that, why not just use zips and a backup folder?
-
As some have said, source backups are still a workable approach if you're a single user. Heck, that's what even teams used before VCS started to become popular.
If you're familiar with 'tar', it's pretty easy to generate archives customized with the file types you want to archive (avoiding object files and binaries, for instance), etc. Avoid using useless storage for files that on top of it compress poorly.
If you're doing that, I really DO NOT recommend automating it if you want to use that as any kind of rough version control. You need to at least specifiy a version/revision number for each backup you trigger, along with a list of changes (the first part can just be in the archive name, the second in a text file included in the archive). Otherwise, that's pretty much just a regular backup. Of course, you can further automate the backup of your source archives and of the current source files as they are.
Point is, whatever approach you use, do not use version control as a backup, and an 'automated' backup as version control. Two different things. Just my 2 cents.
With that said, considering version control, whatever you use for this, is a good step. Many "lone" developers build a bad habit of NOT tracking changes for what they develop. They just add features, fix bugs, and move on, considering that the last version will always be the best one anyway. So starting to keep track of changes is certainly a good thing. You can start with something as simple as Changelog text file listing the changes from one version/revision to the next.
-
at least specifiy a version/revision number
Speaking of which, has this been solved in git yet?
With svn, and others similar, you can take the revision number, which increments sequentially. All my svn projects have the revision number (and mod indicator) automatically embedded, so recognising that the version giving this report is an earlier version than the bug fixed in that version is a no-brainer. No need to dig out the source or fire up any tool.
You can't do that with git so the only alternative seems to be to manually apply a revision reference, but you can't do that for every check-in. If you're running every version of the project (which you probably are to test it) then that means you have to manually sort a version number every check-in. It really needs to be automated anyway, so the act of applying a version reference doesn't change the version.
-
Shit program, though. Installs to Appdata without asking or warning, and when uninstalled doesn't actually remove any of the shit that it's filled the system with.
Hehe, the former I really don't care about (lots of big players put software in Appdata) and the latter I haven't got to yet :P
I think it's safe to say we have different requirements for software ::)
-
You can't do that with git
The kernel Linux has a "dirty" label. Never investigated how it's generated but when you compile an experimental kernel it takes the revision number from Git :-//
-
we have different requirements for software
That's one aspect. The other is the demonstrated mindset of the developer.
-
The kernel Linux has a "dirty" label.
Sounds like it might be useful!
Of course, one way would be to have a revision number server, which dishes up sequential numbers on a first-come first-served basis, but that involves a centralised server which defeats the point of distributed versioning.
-
.
-
Maybe this can help.
It's might do! Thanks :)
-
The kernel Linux has a "dirty" label. Never investigated how it's generated but when you compile an experimental kernel it takes the revision number from Git :-//
Nah, it gives you the commit number which is some random gibberish. It's not sequential like SVN revision numbers.
Pretty sure it's the build system running git to figure out what is being compiled. It also appends a + if there are uncommitted changes.
-
The kernel Linux has a "dirty" label. Never investigated how it's generated but when you compile an experimental kernel it takes the revision number from Git :-//
Nah, it gives you the commit number which is some random gibberish. It's not sequential like SVN revision numbers.
Pretty sure it's the build system running git to figure out what is being compiled. It also appends a + if there are uncommitted changes.
kernel-5.12.0-mips64-dirty # nano tools/power/cpupower/utils/version-gen.sh
# First check if there is a .git to get the version from git describe
# otherwise try to get the version from the kernel makefile
if test -d ../../../.git -o -f ../../../.git &&
VN=$(git describe --abbrev=4 HEAD 2>/dev/null) &&
case "$VN" in
*$LF*) (exit 1) ;;
v[0-9]*)
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" ||
VN="$VN-dirty" ;;
esac
then
VN=$(echo "$VN" | sed -e 's/-/./g');
else
eval $(grep '^VERSION[[:space:]]*=' ../../../Makefile|tr -d ' ')
eval $(grep '^PATCHLEVEL[[:space:]]*=' ../../../Makefile|tr -d ' ')
eval $(grep '^SUBLEVEL[[:space:]]*=' ../../../Makefile|tr -d ' ')
eval $(grep '^EXTRAVERSION[[:space:]]*=' ../../../Makefile|tr -d ' ')
VN="${VERSION}.${PATCHLEVEL}.${SUBLEVEL}${EXTRAVERSION}"
fi
I think they were these lines :-//
-
It's the contents of the commits that matter.
To a point. Knowing that the commit fixes some specific bug or implements some specific feature is perhaps as important when going through history. You might be trying to determine if this version has that fix, and knowing that some weirdo code has changed to some other weirdo form doesn't help that along much.
Sure, and that's down to information embedded in the commit messages, often in a stylised way in the first line "Fixes: 3416" or similar, which tools can pick up. The name of the branch on which the fix was developed is not known and not relevant.
CVS doesn't support merges as a concept at all.
SVN does merges, but what is recorded afterwards (shown by SVN MERGEINFO) is the revision numbers that were merged, not the branch they come from.
-
If you use git like that, why not just use zips and a backup folder?
Because git calculates differences between files in old snapshots and files in new snapshots and doesn't store unchanged bytes again and again, saving space.
As an example, a git checkout of LLVM -- which contains the entire history of the project in your checkout (compressed) -- is smaller than an SVN checkout of LLVM.
The SVN checkout contains just two uncompressed copies of the current files, so you can do diffs of your uncommitted changes locally. For history you have to talk to the server.
-
The kernel Linux has a "dirty" label. Never investigated how it's generated but when you compile an experimental kernel it takes the revision number from Git :-//
Nah, it gives you the commit number which is some random gibberish. It's not sequential like SVN revision numbers.
Pretty sure it's the build system running git to figure out what is being compiled. It also appends a + if there are uncommitted changes.
Sequential revision numbers make no sense outside of a single organisation with a shared central server with a great big shared lock.
If you do something as simple as fork a project, make a series of local changes, and then later decide to upstream your changes -- your revision numbers will clash with the upstream revision numbers.
The SVN model gets unworkable at global scale. It will be simply unusable if people on Mars want to contribute to your project, as them doing a commit will lock up your SVN server for some multiple of the 6 minute to 45 minute ping time.
-
The SVN model gets unworkable at global scale.
A car is pants for continent hopping, but an awful lot of people find them useful because they don't continent hop. Similarly, the OP isn't working at global scale, is unlikely to have a Mars presence, etc.
Sequential revision numbers make no sense outside of a single organisation with a shared central server with a great big shared lock.
Apart from the big shared lock (what's that about?) that identifies many of us.
If you do something as simple as fork a project, make a series of local changes, and then later decide to upstream your changes -- your revision numbers will clash with the upstream revision numbers.
Yes, if you use distributed repos. Not if you use a master repo. Even if you fork off to a separate repo, when you merge back to the first one the revision number will be coherent because it applies only to that repo, which is the only repo for the project.
-
Not everyone is collaborating with Mars. But even on single-person projects you can often be out of communication with your SVN server. If it's on the internet you can be with your laptop on a plane or at the beach, with no internet. If it's on your desktop PCs on your home network, you can be simply not at home with a laptop (and not have a static IP at home).
If you're out of communication with your SVN server you can edit code and prepare one future commit. But you can't commit something and start another commit, and another, and sync up when you get back, the way you can with git. With git you can trivially send a series of commits by email, on a floppy disk (er, sd card), etc.
It's just vastly more flexible and supports whatever workflow you want to use instead of one inflexible way.
-
If it's ...
The possible "if"s are pretty much unlimited and subject only to one's imagination. Not all of them are even remotely (sorry!) relevant. What is an important factor is what "if"s apply to one's own situation and expectations.
It's just vastly more flexible and supports whatever workflow you want to use
Hello? Have you just turned up? The fact is it doesn't support my workflow, otherwise I'd be using it instead!
Where git is more appropriate I will use it, but where it isn't I prefer a tool which works better for my process.
-
Of course, one way would be to have a revision number server, which dishes up sequential numbers on a first-come first-served basis, but that involves a centralised server which defeats the point of distributed versioning.
That's exactly it; you just use git for that too.
You could write a simple shell/Perl/awk/Python script in a dedicated git tree (versions.git?) that manages version numbers, authors, and short descriptions in simple text files, say
YYYY-MM-DD HH:MM:SS major.minor.revision git-commit-tag author@email Description
If you name the files according to their project, you now have an organization-wide database of version numbers, git commit tags (relevant hash), timestamps, authors, and internal descriptions. (Date would be obtained automatically, and author would be taken from current git configuration.)
Note that I chose the field order above so that sorting it will yield date and time order.
Since the script would pull its own HEAD first, then construct the new line, append it, and commit it, it would not be "instant"; it would also have to do a re-pull to verify the chosen version number is still unique in the head (or revert the commit and fail), to be robust. (Because of this, it is better to implement it in parts: say first part a shell script to do the pull, then exec the actual update/modification script.)
However, with a little care, the command line interface could be very simple. In my experience, such "registering" of a version number might take 3-10 seconds per run, depending on the bandwidth to and load of the git server you're using. Not instant, but not aggravatingly slow either.
Hopefully, you'll see how git sits right in to the modular Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy); that to maintain version numbers in an organization, a separate git repository for it is just about perfect match. (Consider, for example, that git will then maintain a separate log of the commits; something not provided by a straight-up database. This can be useful if you have an occasional asshat among your workforce who tries to find others to blame for their own mistakes. Updates and fixes, even done by hand directly to the database file, can be allowed, as long as no collisions are generated by such edits. Again, the commits will leave a log that can be consulted to see if something odd ever occurs.)
As I've mentioned before, you are still looking for a single tool to accomplish the task at hand; but really, with Linux – and Unix in general – is better geared towards splitting the task into parts, each solvable using one or more separate tools. git, or rather its parts, are very much such separated modular tool-lets.
(Note: No snide or denigrating tone is intended, I'm aiming at helpful, only. Here I've tried to show a pattern of solutions to this kind of problems, hopefully showing the "mindset" behind the tool. I'm highlighting the difference, because in my (teaching/tutoring/mentoring) experience, it is this "mindset" or paradigm or approach, that is the hardest to acquire. When one "groks" it, pieces just start to fall into place. I also like the term "grok", because this has nothing to do with intelligence or such; it really is something more akin to social or cultural details. The more experience one has, the harder these can be to "grok", no matter how smart or intelligent or capable one is. It is strange, and I don't understand why it is; but it is what I have observed across dozens of very smart, capable people. Myself very much included; I regularly make a silly ass of myself by not grokking a thing before I stuff my opinion into the subject matter, even though I know better.)
-
That's an interesting approach. Doesn't the version repo conflict with the project repo (that is, the working folder belongs to a single repo)? And if you're using a single master repo (which you would need to so you don't end up with duplicate revisions), why not just have a svn-like repo or database (sqlite might work) which will dish up unique incrementing numbers on demand without needing a script to check for updates and do re-requests?
On a practical level, how would you embed the version number in the project? Important aspects are:
1. Each commit needs a unique (incrementing) version number.
2. The version number for the commit needs embedding in the project.
3. The version number needs to be in the repo as a label so it can be (ideally) viewed in the revision graph or (at least) searched for. I think your suggestion would almost achieve this, but the scripting would have to figure if there is going to be an actual commit before asking for a reference, so it's a bit complicated.
-
As I've mentioned before, you are still looking for a single tool to accomplish the task at hand
I don't think that's appropriate. For one, because we are talking, presumably, a part of a build system that will comprise many tools.
What I am actually looking for is a means to a specific end, but what I'm being pointed to is a different end that will allow a specific means to be used.
-
That's an interesting approach. Doesn't the version repo conflict with the project repo (that is, the working folder belongs to a single repo)?
No, because you put your local copy of the version repository in a separate folder:
$HOME/projects/versions/
$HOME/projects/foo/
$HOME/projects/bar/
You could also make the version git a submodule of each project,
$HOME/projects/foo/
$HOME/projects/foo/versions/
$HOME/projects/bar/
$HOME/projects/bar/versions/
but the repetition wastes some disk space, when a developer works on many projects at the same time.
In both cases, since the version repo is separately maintained, the version information is available to all developers, even those without access to the projects themselves, so interactions between projects should be easier to plan.
And if you're using a single master repo (which you would need to so you don't end up with duplicate revisions), why not just have a svn-like repo or database (sqlite might work) which will dish up unique incrementing numbers on demand without needing a script to check for updates and do re-requests?
Because with the separate version repository, you have more information, and any errors can be corrected later, as the "database" is just a text file (per project).
On a practical level, how would you embed the version number in the project?
I'd tag the commit. See e.g. Teensyduino git (https://github.com/PaulStoffregen/cores/tags) at github.
1. Each commit needs a unique (incrementing) version number.
Each git commit has an unique hash already. These are not incrementing, though.
2. The version number for the commit needs embedding in the project.
Internally, use the commit hash. Externally, use the tag.
(For example, you can use git pull repository tag tag to pull everything up to that specific tag.)
3. The version number needs to be in the repo as a label so it can be (ideally) viewed in the revision graph or (at least) searched for.
Do tags not fulfill exactly that purpose?
In a very real sense, the version repo duplicates tags, really, except being "central", it reduces the number of conflicts between local git repositories – for example, if one group works on feature X and another on feature Y, they can work on them separately, with (initially locally minimally tested) tagged versions merged into an "upstream" repo; with designated persons working on merge conflicts. This works fine even when submodules are used.
As I've mentioned before, you are still looking for a single tool to accomplish the task at hand
I don't think that's appropriate. For one, because we are talking, presumably, a part of a build system that will comprise many tools.
What I am actually looking for is a means to a specific end, but what I'm being pointed to is a different end that will allow a specific means to be used.
Let me rephrase, then.
In #118 (https://www.eevblog.com/forum/programming/a-version-control-system-for-embedded-work-which-doesnt-need-a-phd/msg3625789/#msg3625789) you said "[git] doesn't support my workflow", and I am trying to show the pattern of how it does.
The difference (as far as I can tell) is that it does not provide a built-in feature (atomically increasing version numbers) you expect from other version control systems, nor monotonically increasing identifiers for individual commits.
The solution in "git-land" is to use multiple repositories, and a "master" one for the atomic/monotonic/cross-project information; here, the database is a plain text file (so it is managed similarly to source code, including commit messages et cetera), typically – but not necessarily – accessed via helper scripts. For the version case, it is somewhat an overview of changesets across the projects in an organization.
The one thing that gives me pause is the need for monotonically increasing commit identifiers, as I don't see why –– and I mean, I am puzzled and want to know more, as there is evidently something about your workflow I am missing or misunderstanding. Isn't a commit hash and the timestamp of the commit sufficient, or even better? Note that timestamps of form YYYY-MM-DD HH:MM:SS sort correctly as text; perhaps this is relevant here? It is close enough to ISO 8601 (https://en.wikipedia.org/wiki/ISO_8601) (YYYY-MM-DDTHH:MM:SSZ or YYYY-MM-DDTHH:MM:SS±hh:mm) to be portable as well, while still being somewhat human-readable.
-
In #118 you said "[git] doesn't support my workflow", and I am trying to show the pattern of how it does.
Well, thanks for working through all that to show me how the pattern would work. However, it falls over at these two places:
Quote from: dunkemhigh on Today at 12:21:38
1. Each commit needs a unique (incrementing) version number.
Each git commit has an unique hash already. These are not incrementing, though.
(I made a goof there and used 'incrementing' where I should probably have used 'sequential'.)
It needs the sequential version numbering for each commit.
Quote from: dunkemhigh on Today at 12:21:38
2. The version number for the commit needs embedding in the project.
Internally, use the commit hash. Externally, use the tag.
(For example, you can use git pull repository tag tag to pull everything up to that specific tag.)
I'm not sure I follow, sorry. Internal to what? 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. It's doable, yes, but hardly optimal.
The difference (as far as I can tell) is that it does not provide a built-in feature (atomically increasing version numbers)
Yep, that.
nor monotonically increasing identifiers for individual commits.
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.
... you expect from other version control systems ...
Don't care how it's done, that's the aim. It can be made to happen with git, but it's messy and it relies on there being a single repo. 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.
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.
Is this important? I think so. When you release some product it will be version x.y, with increasing numbers. The end user will know that 1.2 came before 1.3. If he is on 1.2 then he knows he should upgrade to 1.3, there might be a bug fix (or a new bug), etc.
Suppose you want to run an Apple OS: do you install Mojave or Capitan or what? I would have no idea at all, but I can tell you that Mojave is the one because it is version 10.14 whereas Capitan is 10.11.
Even where just names are used, typically they will be in alpha order so they are not completely random (but you need to be hip to the scheme to realise). But even if you don't twig that Gingerbread came after Froyo, you will know that 2.3 is later than 2.2.
So increasing version numbers are important to identify progression easily. No-one wants to have to google names (or 7-digit hex codes) to find out relative age. And then do it for every one of a series. But... for some reason all that goodness stops at writing the code. It's still there - we manually applied tags or labels, which are version references, on release versions, but for some reason the intermediate versions aren't important in that way. What's sauce for people up the line isn't for us before we hand it off to them. It's just a coincidence that that's where the version control has a problem, I'm sure. It certainly isn't because we suddenly don't need to know the temporal order of stuff.
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?" It needs to be something short and simple, so memorable. A date stamp and hash is essentially a GUID, and you know how simple they are to trot off the tongue!
Although, come to think of it, 210812191135 isn't too bad. Still tricky to spot when scrolling though it would benefit from being broken up: 210812-1911-35 maybe. But then you need the rest of the version number as well, so we're back to a forgettable 20-digit number.
Like I said before above, it's doable but smacks of taking the scenic route just to avoid an unliked road.
-
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. ;D
-
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.
Is this important? I think so. When you release some product it will be version x.y, with increasing numbers. The end user will know that 1.2 came before 1.3. If he is on 1.2 then he knows he should upgrade to 1.3, there might be a bug fix (or a new bug), etc.
So we hit the root of your problem.
Product release numbers are almost completely unconnected to version control commits. There will usually be dozens or thousands of the latter for every one of the former.
Commits happen often many times a day.
Product releases happen something from once a week to once a year or longer. They are very deliberate things. Usually extensive testing is done. A maintenance branch is made for version 1.3 so development can continue on the main branch while bugs found in the release are fixed without mixing in untested unannounced new features.
Usually there will be a plain text file called "Version" in the top level of the project. This is often incremented and committed by hand just after a version branch is created. If the old was "1.3-devel" then the release branch will be updated to "1.3-rc1" and the trunk to "1.4-devel" (or similar).
This is such a small amount of work compared to everything else involved in doing a release that no one cares. But you might script it.
-
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. ;D
Because someone -- not the OP -- is insisting on replicating incidental features of their preferred tool in order to consider any other tool.
Simple use of the tool that has been by far the most popular for the last dozen years (with nothing else seriously on the horizon) is just that ... simple.
-
So we hit the root of your problem.
Finally, yes!
Product release numbers are almost completely unconnected to version control commits.
Yes, but you are missing the wood for the trees.
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.
Product releases happen something from once a week to once a year or longer. They are very deliberate things. Usually extensive testing is done.
Yes, but irrelevant. Having version numbers, and having them increase is in no way related to 'deliberate' things or tested things. Or regular or infrequent things. Think about it: you would never say "Oh, we made 20 commits today, and all before lunch so they are all the same".
Usually there will be a plain text file called "Version" in the top level of the project.
Sure, that's how you get it into the project.
This is often incremented and committed by hand just after a version branch is created
Sure, that's how you define the major parts of the version number.
So are you saying that when an error pops up, or you look at the version output of the product, it is sufficient to know it is one of the very many - remember, you said there are lots of commits - versions of this branch? Knowing which particular commit is unimportant?
-
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 :)
-
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!
-
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.
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 (https://github.com/PaulStoffregen/cores/commit/224b97bb3ff408ce60dd6f7bde13da7c20c825cf). This is a fixed reference to this particular commit.
This commit is tagged 1.51 (https://github.com/PaulStoffregen/cores/releases/tag/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.
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.
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.)
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.
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.
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.
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.
-
Perhaps an example will clarify.
Consider Teensyduino commit 224b97bb3ff408ce60dd6f7bde13da7c20c825cf (https://github.com/PaulStoffregen/cores/commit/224b97bb3ff408ce60dd6f7bde13da7c20c825cf). This is a fixed reference to this particular commit.
This commit is tagged 1.51 (https://github.com/PaulStoffregen/cores/releases/tag/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.
-
.
-
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.
-
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.
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
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
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 :-+
-
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).
-
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.
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 (http://oeis.org/), so I assumed these definitions were universally agreed on, sorry.)
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.
-
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.
-
The On-Line Encyclopedia of Integer Sequences
!
That's a rabbit hole to fall down.
-
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 (https://math.stackexchange.com/questions/1675498/references-to-these-functions-relating-to-binary-trees-and-binary-digit-counting), given two perfect binary search trees,
(https://www.nominal-animal.net/answers/trees.png)
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 (https://oeis.org/A000265), \$i(k, N)\$ are subsequences of OEIS A131987 (https://oeis.org/A131987), and \$k(i, N)\$ are subsequences of A101279 (https://oeis.org/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.
-
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
-
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
-
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.
-
Ahem. Lots of projects rebase their feature branches before merging to master to obtain a clean and logical changelog, even if a fake one ;)
-
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
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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?
-
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.
-
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 regular backups of a project are just that: a backup.
They don't help in visualizing the evolution of the code.
They don't help tracking when a problem has been introduced (or maybe has always been there) and why.
They don't help with versioning.
They don't help with trying alternatives and quickly switching between them, while keeping track of what has happened.
They don't help should anyone cooperate with you.
They don't help if you want to develop in two places or on two machines.
You need to come up with a naming strategy and stick to it.
You need to remember to do the copy.
You need to rummage through zip file or directories to find the right old revision in case you need to check something.
After a while, for me at least, "you are in a maze of twisty little passages project dir, all alike" but all different.
I'll describe my use, in both work (in a cursory way, I'm not sure about how many beans I can spill) and home environment - this is all based on git, because to me it doesn't make much sense to learn another one: I have to use it for work, and it covers my home needs very well.
At work, I do not code much nowadays, though I'm still involved in many code reviews and in creating the occasional simulation, (I tend to use python), or mobile radio network equipment simulator (in C, mostly).
The process there is well defined and make use of git, augmented by one of the most common code collaboration tools.
As the part I'm working on is quite large, and we have teams all over the world, there's no doubt that good use of a VCS is paramount.
We have many repositories for the various components, and meta repositories to keep them together for the complete system builds.
It all works very well (we are large, the IT departments takes care of servers updates/repair/backups etc. - these parts are completely transparent to us when e.g. when asking for a new repo).
Depending on the project, there are slightly different strategies on git handling (merges vs. rebases, number of non-local branches etc.).
As everybody is familiar with git, some leeway is given to the teams to find their best options.
At home, I do embedded code for fun, 90% of my projects are just for me, but sometimes a friend joins in.
I'm also based in two nations, separated by some thousands km, and have a number of multi-platform (Win, Linux, FreeBSD VMs) machines in each.
This means that if I want to continue developing something regardless of where I am (in the house or in Europe), I need a distributed development VCS.
Since I had to learn git for work, I see no point in using something else - probably the same can be accomplished with any competent, modern, VCS.
For mobility, as git repo server, I use Gitea (https://gitea.io/en-us/) run in a FreeBSD VM - it's lightweight and very simple to setup.
Repos are kept on my NAS and regularly backed up to a normally offline disk, but one of the advantages of git is that any complete clone is a backup in itself (if regularly fetched) and I have many, on different machines in the same or different countries - it will be quite surprising if I were to lose any code in a HW or SW mess up.
I extensively use branching to investigate problems or try different things, with merges towards a main branch when I'm satisfied with the result.
Apart from the very temporary ones that stay local, I push them to the Gitea server due to the many machines/many countries situation.
I tend to use merges more than rebases, especially when a friend is involved - due to the fact that I have very few local-only branches.
Very little tagging - the HEAD of 'main' branch is always cleanly compilable, working, and reasonably tested.
Even on experimental branches, I tend to only commit and, especially, push code that compiles cleanly (might not be working - I note in the commit message if that's the case).
This WoW works well enough even when cooperating with a friend or two.
While I do not eschew the command line for some repo maintenance, 90% of the operation are a click away in VS Code with the integrated support. Any good git extension (I use gitgraph, essential but enough for me) can give some convenience (e.g: click on one commit, Ctrl-click on another to see the diffs).
I would never, ever, go back to a naked directory, its associated handling annoyance and the difficulty to have a clear understanding of the history (especially with experimental versions).
The additional workload (hobbyload?) associated wit git has been for me, negative: I spend less time in figuring out what was changed and when, and saving the day's (or hour, or 5') results is one click (and one commit message) away.
-
.
-
For simple / small projects by one developer you don't need version control system but peter-h, judging from all the topics you are creating you have a fairly complex project with many moving parts and lot of problems, a VCS is definitely a good tool for you. Seeing the issues you'd benefit from being able to go back to a certain version, see from a log / diff what changed and where, and use descriptive commit messages. You may not need branching as a single user, but this trivial pattern will prove easy for you:
git diff
oh I did that on that file!
git add thing.c
git commit -m "did that"
oh what else did I do?
git diff
git add another.c
git commit -m "I created this bug here"
Oh, time to push somewhere so I can access it elsewhere, kind of works as a backup as well
git push
what the heck did I do?
git log
Oh, what's the difference between those two?
git diff acdc1234 abbacd56
Oh, I see, let's go back and try this old one
git checkout abbacd56
make clean; make
Oh I see.
git checkout master
make clean; make
... no rocket science here.
Git is of course more powerful than that and is very effective when large groups need to branch and merge, but you don't need to go all the way first, the extra power is not a burden, just use what you need and know how to.
-
Use a VCS, it helps.
From this thread and the many others, I would say that the OP, while always being kind in their questions and answers, are quite entrenched in their ways.
This often comes with experience, and with relying on what has worked before, but sometimes (oftentimes, nowadays) we need to depart from the known and tried; in these specific cases (e.g. VCS, optimizations) it's not that we are collectively preaching some fancy, extreme and untried novelty, though.
I'm starting to think we are a bit wasting our energies: we start with an innocuous question, the thread wanders here and there (as it's bound to do in any technical conversation) and good points are made, discussed and maybe dissected - then the OP more or less comes back and says:
"Ok thanks to all very much, very informative and interesting. I'll just go on like before".
Maybe it's just me... :-//
-
... no rocket science here.
Exactly, no PhD required, just a bit of effort to get over the learning curve, ...then you wonder why you didn't do it years ago |O
Maybe it's just me... :-//
Nope, me too.
-
Maybe it's just me...
No. I remember when I was new to this stuff and trying to get into it. There were two hurdles: appreciating what it could do for me, and learning how to do it. Even if you think you know what and why, you've then got to put that into practice before finding if it does indeed work, and learn the practice at the same time.
That's why I suggested, earlier in the thread, downloading a repo from github to have a go with. It's like when you start programming with some weirdo all-in-one IDE, having an existing project to browse and play with is really useful.
I also suggested trying both git and svn (unlike some - ahem - I can separate what I want from what might be useful for others). A GUI version of each is available, and I would suggest that over the command line because of the graphical history, and discoverability of all the options.
-
I remember when I was new to this stuff and trying to get into it. There were two hurdles: appreciating what it could do for me, and learning how to do it. Even if you think you know what and why, you've then got to put that into practice before finding if it does indeed work, and learn the practice at the same time.
That's why I suggested, earlier in the thread, downloading a repo from github to have a go with. It's like when you start programming with some weirdo all-in-one IDE, having an existing project to browse and play with is really useful.
I also suggested trying both git and svn (unlike some - ahem - I can separate what I want from what might be useful for others).
This is good advice. :-+
I would emphasize the need to verify that the chosen repo (be it git or svn or something else) *works*. I mean, there are a lot of github repos (especially by hobbyists, and companies that are using it more as a drop point than a development system) that don't really have branches or tags to pinpoint specific versions, and are just a continuous development stream. The problem there is that outsiders cannot then tell what state the head is, or how to pick a point to fork for a "stable" version.
The criteria I use is clean-looking code (stuff like unused lines removed instead of commented out), sane (directory) structure, documentation, versioning/branches/tags with an user-directed feature summary (as opposed to references to chat discussions among developers – "this implements the features suggested by Pete"), and for git, pulls from other repos. If there is a mailing list discussing patches and changes, so you can lurk to see how they do stuff, even better. In some ways, a long history can indicate stability/maintenance, but it may also mean silly anachronisms no longer really appropriate are retained, because they still technically work.
There is just too much garbage thrown out there, so it pays to be careful. If you have the time, examining several repos (and their logs), with an eye on whether their workflow seems efficient or not, is in my opinion well worth it. Similarly, comparing different introductions/how-tos on the same topic, can be very informative.
-
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?
Here's something that hasn't been mentioned yet.
You're the sole coder. But you have a main desktop computer, and you have a laptop. You want to work on your projects on either machine.
Version control helps make sure that you always work with the the latest version of your sources.
I'll use the Subversion workflow because it's most familiar to me. Git has the same.
My desktop machine has a "working copy" of my project. I make changes to my code, I test them, they're good. I commit the changes back to the repository.
The first time I want to work on that project on my laptop, I create a new "working copy" on that machine by checking out the HEAD of the repository. I make my changes, test them, then finally commit the changes back to the repository.
Now at this point in time, the working copy of the code on the desktop is out of date. But there is a simple way to update it: run svn update on the working copy. This pulls all of the changes made to the code from the repo since you last made a commit from your desktop. This includes all of the changes you made on your laptop. Now your laptop and your desktop machines have the same code.
Make changes on the desktop, commit. Continue as you wish. The next time you use the laptop for this work, you do the simple svn update and all of the changes are pulled and your laptop's working copy is brought up to date.
The lesson: both machines have what is called a "long term working copy." Every time you sit down to do work on either of them, the first thing you should do is the svn update to ensure that the machine's working copy has all of the latest changes. Then the last thing you should do is to commit those changes back to the repo.
This works and is simple, but obviously it requires some discipline.
The next question: "what happens if I work on my laptop and forget to commit the changes before I start working with the desktop? Or what happens if I start working on the desktop without doing svn update to pull changes made on the desktop?" This is actually a common problem: two people working on the same code at the same time, making changes, and one commits before the other. In all of these cases, a "conflict" results, and Subversion (and git) have procedures and tools to handle the conflicts.
-
That is a good explanation of the M.O. of a VCS. I was very confused with the terms of Git and the guideline below, although simple, brought me out of my confusion at the time. This does not have details about the setting up the server part of it, though.
To start from blank canvas, you have to do the command init (to create a repository on an arbitrary directory of your system), copy the files to be included on the VCS, then issue the command add (notify Git that these files are now version controlled), commit (with a meaningful message about the changes) and push (so the commit is actually copied to the server).
When returning to work, the first thing you do is pull (copy the modifications on the server to your local machine), make modifications, commit (with a meaningful message about the changes) and push (so the commit is actually copied to the server). Rinse and repeat if you change the local machine from desktop to laptop, for example.
Try to avoid conflicts (as mentioned above), as solving them is the most error prone operation as it is heavily manual.
Once more advanced, you can check other commands that facilitate your life.
(edit) minor issues with the process
-
copy the files to be included on the VCS, then issue the command add
Shortcut for svn: create repo, checkout to working directory, done. Just create files as you go along and commit to check them in.
Also for svn in case you started before realising (or remembering) you want the stuff under VCS. Create repo as above and checkout to the working directory, then commit. Existing files will be left alone, and you just mark them as versioned to check them in.
-
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?
TBH, you don't need ::) VCS at all since
- you have already solved main problem issue aka backup of projects
- you never experienced any issues problems that VCS solves
-
copy the files to be included on the VCS, then issue the command add
Shortcut for svn: create repo, checkout to working directory, done. Just create files as you go along and commit to check them in.
Also for svn in case you started before realising (or remembering) you want the stuff under VCS. Create repo as above and checkout to the working directory, then commit. Existing files will be left alone, and you just mark them as versioned to check them in.
@dunkemhigh, I'm sure you know this, but for peter-h and rsjsouza, with svn, after you create a repo (or if you intend to use one which already exists), you have to do svn import on the files (directory containing the files) to get them into the repo. Then check out the files to a working copy.
I have little "skeletons" that I use to create new projects. They live in the repository. One is called skeleton-fpga and it's nothing more than a directory tree that I use for my FPGA designs:
skeleton-fpga/
/trunk/
/src/
/testbench/
/fitter/
/branches/
/tags/
And when starting a new project, I do an "in the repository" copy of skeleton-fpga to new_fpga_project_name (this is simple with TortoiseSVN but is also easy to do from the command line or with Xversion on a Mac). Then you simply check out new_fpga_project_name to a new working copy. Then in the working copy you create your sources etc in the usual way and do svn add to put them under version control. The first commit will put the new files into the repo.
-
@dunkemhigh, I'm sure you know this, but for peter-h and rsjsouza, with svn, after you create a repo (or if you intend to use one which already exists), you have to do svn import on the files (directory containing the files) to get them into the repo. Then check out the files to a working copy.
No, you don't. That's the point of the shortcuts I posted, and I just ran through an example to be sure. I used TortoiseSVN which may make things slightly easier, but these are the steps:
1. Create repo directoryt (R:\svn_test)
2. Create repo in that directory (right click, tortoisesvn, 'create repository here')
3. Optional: tick yes to create the standard trunk, branch and tag folders.
4. Create working directory (R:\working)
5. Check out head (right click, 'SVN Checkout...'). Select repo (file:///r:/svn_test), popup repo browser, select trunk.
The working folder is now under SVN control and the HEAD checked out.
6. Create new file (test.txt)
7. Right click working folder, 'SVN Commit...', tick test.txt, OK
Typing that took five times as long as dreaming it up and doing it!
-
@dunkemhigh, I'm sure you know this, but for peter-h and rsjsouza, with svn, after you create a repo (or if you intend to use one which already exists), you have to do svn import on the files (directory containing the files) to get them into the repo. Then check out the files to a working copy.
No, you don't. That's the point of the shortcuts I posted, and I just ran through an example to be sure. I used TortoiseSVN which may make things slightly easier, but these are the steps:
Ah, ok -- I admit to never using the "create repository here" feature of TortoiseSVN. That's because we have a repository set up on a server for all of our work, and I have a personal-projects server set up on my web host. Perhaps this feature of TortoiseSVN was added so that the user comfortable with the git workflow would seem at ease? (I know that the fsfs repository type has existed since the start of SVN.) Indeed since the dialog has an option for creating the default folder structure, the expectation is that the repository is for a single project.
But it does answer our friend peter-h's question about "how to begin?"
This leads to a reasonable question: where to create this repo? This is one of the questions I asked here (https://www.eevblog.com/forum/programming/real-world-git-use/) that was not addressed. The answer could be "anywhere," I suppose.
-
The answer should be on a server or NAS that can be reached by all computers you want to use the repository on and which is regularly backed up. If you're repository gets a bitloss or irrecoverable error you still have the checked out version, but then you need to create a new repo and check the old one in so it is better/easier to back it up IMO.
A repo on the same single computer is possible but it leaves you with an SPOF.
-
Perhaps this feature of TortoiseSVN was added so that the user comfortable with the git workflow would seem at ease?
Highly unlikely since it predated git :). The default directory structure option is relatively new though, I think. I used to use my own structure (the trunk/branch/tag structure can be really confusing for new users), but eventually succumbed.
where to create this repo?
There must be somewhere that gets backed up regularly (if not then the answer is indeed 'anywhere'). I chose a NAS because that gets automatically backed up every night (more often than my PC, in fact) and it's also not the PC so less prone to fat finger syndrome. A share that just holds repos (in fact, every repo) works for me.
However, everyone is different and I would suggest that wherever is chosen at the start, somewhere else will likely turn out to be a better choice once some experience has been gained. Peter-h already has a backup strategy for the project, so 'with the project' would be fine to start with, perhaps.
-
Perhaps this feature of TortoiseSVN was added so that the user comfortable with the git workflow would seem at ease?
Highly unlikely since it predated git :). The default directory structure option is relatively new though, I think. I used to use my own structure (the trunk/branch/tag structure can be really confusing for new users), but eventually succumbed.
It's funny, I've been using SVN since before it was v1.0, and I started using TortoiseSVN once I learned about it, and I never even noticed that feature. I guess if you don't (think you) need it, you won't look for it!
I've always used the branch/tag/trunk structure. (Remember that TortoiseSVN enforces the immutability of tags -- check out a tag, change something, and try to commit the change back and you'll see.) But I have started to see how it can be limiting. We've all made a branch and then worked on it and then released something built from the branch, even if it's a thing for a specific customer. Of course you want to tag what you release, so then you have to decide, "where should I put this tag?" (But this is a data management problem, not a version-control problem.)
where to create this repo?
There must be somewhere that gets backed up regularly (if not then the answer is indeed 'anywhere'). I chose a NAS because that gets automatically backed up every night (more often than my PC, in fact) and it's also not the PC so less prone to fat finger syndrome. A share that just holds repos (in fact, every repo) works for me.
At the office the SVN server is on a Linux box in the closet, and I set up a cron job to run the backup at 3 am. My personal repo is on my mail/web host's server. I have a Synology NAS at home and I can set up a Subversion server on it (they also offer Git), and the only reason I haven't done so is because I want to be able to access the server outside of my home network.
However, everyone is different and I would suggest that wherever is chosen at the start, somewhere else will likely turn out to be a better choice once some experience has been gained. Peter-h already has a backup strategy for the project, so 'with the project' would be fine to start with, perhaps.
Agreed.
-
This is not a great thread for recruiting people to using VCS
Really?
I thought that the consensus was looking pretty much like "if your needs are simple, pretty much any of common VCS systems will have an "easy" subset that will work fine. Use whatever you think will look good on your resume."
The discussions of more complicated scenarios that may or may not present problems for one or more of the VCS systems are ... for more complicated needs.
-
This is not a great thread for recruiting people to using VCS
Really?
I thought that the consensus was looking pretty much like "if your needs are simple, pretty much any of common VCS systems will have an "easy" subset that will work fine. Use whatever you think will look good on your resume."
The discussions of more complicated scenarios that may or may not present problems for one or more of the VCS systems are ... for more complicated needs.
Absolutely.
I would rather see people with one-person projects with half a dozen files in them using CVS or even RCS than no VCS at all. (I draw the line at SCCS)
It's not like you need to go out and spend $100 or $1000 on something you might not like. Everything discussed here is absolutely free and open source.
-
I have little "skeletons" that I use to create new projects
...
skeleton-fpga/
/trunk/
/src/
/testbench/
/fitter/
/branches/
/tags/
similar to the one used in OpenCores. Good! Great! :D
-
I have little "skeletons" that I use to create new projects
...
skeleton-fpga/
/trunk/
/src/
/testbench/
/fitter/
/branches/
/tags/
similar to the one used in OpenCores. Good! Great! :D
I'm not sure whether that's a compliment or a dis, but ... I can't remember the last time I looked at OpenCores! Does it still exist? I just remember it was a dumping ground for never-completed half-baked ideas.
-
I'm not sure whether that's a compliment
Compliment for the skeleton idea :D
It's a nice idea because it keeps the project arranged neatly and in order.
It's something I have appreciated about OpenCores!
-
I'm not sure whether that's a compliment
Compliment for the skeleton idea :D
It's a nice idea because it keeps the project arranged neatly and in order.
It's something I have appreciated about OpenCores!
Thanks! I'm a big believer in organizing projects, not only for someone else who has to look at it, but also for me in case I have to revisit it in six years. Like I just had to do.
One of my pet peeves (not posted in that other thread!) is getting example code from a vendor which is just a big Xilinx project with the sources and build results and test bench stuff ALL IN THE SAME DIRECTORY. It makes me seriously wonder about the reliability of the product supported by the example code.
-
If you really hate git for whatever reason, use at least Subversion (SVN). It fixes both the lack of atomic commits (the entire commit either passes or fails, it is never partial as can happen with CVS which operates file-by-file), the repository is much more stable than anything CVS ever had and merging is more sane. And it is actually still maintained.
As an SVN user: it was a learning curve but I like git much better nowadays. The integration into Eclipse (which is what the OP is basically using) is really good. Either way in my experience it is not a good idea to do merges blind; I always do these semi manual by using the GUI from Eclipse to select which chunks use from a different branch and which not.
-
If you really hate git for whatever reason, use at least Subversion (SVN). It fixes both the lack of atomic commits (the entire commit either passes or fails, it is never partial as can happen with CVS which operates file-by-file), the repository is much more stable than anything CVS ever had and merging is more sane. And it is actually still maintained.
As an SVN user: it was a learning curve but I like git much better nowadays. The integration into Eclipse (which is what the OP is basically using) is really good. Either way in my experience it is not a good idea to do merges blind; I always do these semi manual by using the GUI from Eclipse to select which chunks use from a different branch and which not.
It's probably been a while since I said this, so here goes again.
If you have to merge branches that both have significant development on them (and a high probability of clashes somewhere) then use Micheal Haggerty's git-imerge script.
https://www.youtube.com/watch?v=FMZ2_-Ny_zc (https://www.youtube.com/watch?v=FMZ2_-Ny_zc)
It rapidly merges the (initial) things from each branch that *don't* conflict, and then shows you the exact pairs of commits from each branch that *do* conflict, with all previous non-conflicting changes from both branches already applied.
You get to resolve the conflicting changes in their proper context, which makes it much much easier. And you do it once.
Conflicting changes to the same bit of code are not always easy to resolve and this is NECESSARILY SO, completely independent of any RCS. One person decided that code needs to be modified to do something different, and someone else modified it to work in a 3rd way. Sometimes you can find a way to achieve both of the objectives, but sometimes they are simply at odds with each other.
For example someone in your company modifies a buffer size from 1 KB to 256 bytes to decrease memory usage on some small machine, while someone in the upstream project modifies the same buffer from 1 KB to 16 KB for better performance.
That's an utterly trivial example. In this case you'd no doubt decide size beats speed in your application and keep the 256 byte change. There are far more complex examples which are hard to understand what is happening and the ramifications, let alone the right solution. But having the ACTUAL COMMIT that conflicts in each branch in front of you, along with the commit messages, makes it much easier to figure out what is going on. And without the 2000 later commits in the upstream code that might have modified the same lines of code again later for another reason.
I've used this to keep private forks of LLVM (for RISC-V and for a secret CPU at Samsung) up to date with upstream development and it's an absolute life-saver.
git is amenable to 3rd party tools like this, because it exposes the plumbing and everything is local until you decide to push your dozens or thousands of commits (whether to your colleagues or to upstream). SVN isn't.
-
If you really hate git for whatever reason, use at least Subversion (SVN). It fixes both the lack of atomic commits (the entire commit either passes or fails, it is never partial as can happen with CVS which operates file-by-file), the repository is much more stable than anything CVS ever had and merging is more sane. And it is actually still maintained.
As an SVN user: it was a learning curve but I like git much better nowadays. The integration into Eclipse (which is what the OP is basically using) is really good. Either way in my experience it is not a good idea to do merges blind; I always do these semi manual by using the GUI from Eclipse to select which chunks use from a different branch and which not.
It's probably been a while since I said this, so here goes again.
If you have to merge branches that both have significant development on them (and a high probability of clashes somewhere) then use Micheal Haggerty's git-imerge script.
It rapidly merges the (initial) things from each branch that *don't* conflict, and then shows you the exact pairs of commits from each branch that *do* conflict, with all previous non-conflicting changes from both branches already applied.
You get to resolve the conflicting changes in their proper context, which makes it much much easier. And you do it once.
That is exactly what Eclipse can do as well. The problem however is that when multiple people are working on the same code, not all changes made are good ones. So those need to be checked / filtered out. And then there are conflicting changes and stuff that needs to stay instead of being thrown out during merging. Again: in my experience with working on the same code by multiple people is that you really want to do merges manually / closely supervised. After such a merge I check the result against the branch(es) that got merged AND the previous version to see if all changes made it in an nothing got deleted.
-
I don't think Eclipse helps with merging different branches with dozens or thousands or commits against each other. One commit, sure.
-
I don't think Eclipse helps with merging different branches with dozens or thousands or commits against each other. One commit, sure.
I do use it to compare versions of large projects (like the Linux kernel) against various branches / commits and cherry pick what I want to keep or remove. The 'Team synchronising' perspective is quite useful. I'm not saying it is the best tool out there but it pretty much does what the guy outlines in the video you linked to.
-
I didn't notice that Eclipse (Cube IDE in my case) offers version control, and a search suggests it is done with plug-ins for Git or others.
Funnily enough the main issues I have with Eclipse are with it not rigorously checking datestamps before it does a build. I am often doing edits on a second machine (at home v. at work). I now make a point of treating the work one as "throw-away / test only" and keeping the master at home (it's my own business so I work at home a lot anyway, 7 days a week) and I back-edit changes tested at work to the home machine over RDP. If you edit files on another machine and drop them into the project directory (in or outside of Cube) then Cube gets confused, doesn't reliably notice the later datestamps, and does weird things, so after dropping in anything edited elsewhere one has to do a Clean and then Build.
Same of course if I am doing any edits on a laptop while on holiday (you can tell it's my own business; no normal employee would be doing any company stuff on holiday ;) ) and then again dropping files back in is fine so long as you do a Clean and Build.
Oh and a re-Index is generally a good idea anyway.
And I keep a totally rigorous regime of backups (the whole 150MB project directory, not incremental like a VCS does) after every substantial bit of work, and certainly every day, to a separate physical device. Plus a 3am auto backup to an off site machine but that one keeps just the one copy.
Of course if I break something then I can't easily just step back versions until it works again. I can only go back to the last whole-project-backup.
I have seen the compare tool in use and it is really impressive but have never worked out how to use it. So far I use the Compare 2 files macro in notepad++ :)
-
SCM would help with syncing both machines. Check in at one, update at the other, bosh. You can ignore any intermediate files that get built (*.o and the like) and just do a full build after the update. Only thing to remember is to check in before you leave home, but you can make that become a habit and it's good for you anyway :)
The compare tools... I hate them. It can be difficult to figure out what you're getting from the inputs. (I have the same issue with Word's track changes - my missus has the thing displaying all the time and easily knows what it's all saying, whereas it's just a confusing mash to me.) My preferred compare tool, which plays nicely as a plug-in to other apps) is Beyond Compare:
https://www.scootersoftware.com/features.php (https://www.scootersoftware.com/features.php)
Too many features and uses to list here. It's my go-to compare/sync tool and a mere right-click away.
-
I didn't notice that Eclipse (Cube IDE in my case) offers version control, and a search suggests it is done with plug-ins for Git or others.
Funnily enough the main issues I have with Eclipse are with it not rigorously checking datestamps before it does a build. I am often doing edits on a second machine (at home v. at work). I now make a point of treating the work one as "throw-away / test only" and keeping the master at home (it's my own business so I work at home a lot anyway, 7 days a week) and I back-edit changes tested at work to the home machine over RDP. If you edit files on another machine and drop them into the project directory (in or outside of Cube) then Cube gets confused, doesn't reliably notice the later datestamps, and does weird things, so after dropping in anything edited elsewhere one has to do a Clean and then Build.
You can tweak these settings from the project specific settings (internal or external builder, number of parallel processes) and from the workspace settings (how files are tracked, automatically saved before a build, etc)
-
Do you mean these
(https://peter-ftp.co.uk/screenshots/20210826283812309.jpg)
-
No, you can choose these in the build configurations for the project as these can be target & OS dependant (for example using the internal builder on Windows and the externel makefile builder on Linux).
-
Point is, whatever approach you use, do not use version control as a backup, and an 'automated' backup as version control. Two different things. Just my 2 cents.
Agreed. Although ... Devil's advocate mode what's the worst that could happen? No seriously, what is the worst thing that could happen if you use version control as backup, and automated archives as version control? >:D
With that said, considering version control, whatever you use for this, is a good step. Many "lone" developers build a bad habit of NOT tracking changes for what they develop. They just add features, fix bugs, and move on, considering that the last version will always be the best one anyway. So starting to keep track of changes is certainly a good thing. You can start with something as simple as Changelog text file listing the changes from one version/revision to the next.
Guilty as charged, especially in the past. :-[ Typically it would go something like "Mmmh, I wonder if this would work..." followed by a bunch of small scripts/experiments, finding/reading/misplacing papers, making some notes, and before you know it you have a collection of stuff that really could do with some version control. Especially since this kind of experiment more often than not either fizzles, gets interrupted, or runs into a roadblock. So it can be on the backburner for days, months, sometimes even years... Lets just say that I have never had a regret of this form: "Gee, this repo sure is useless. Eating up all this precious diskspace. I sure wish I never created a repository for this." On the other hand the "#^%@!! why didn't I just create a repo for this EARLIER?" variety has been known to happen every now and then. |O |O |O
As for the original question, yet another git user here. Fairly typical path taken: CVS -> SVN -> GIT for the most part, with some mercurial here and there. For new projects preference is git, but mercurial is fine too. Subversion is a most definite maaaaaybe, and CVS is a hard pass.
-
what is the worst thing that could happen if you use version control as backup
You lose everything.