Best way to keep two machines in sync with FreeBSD

Yeah mer, good example of how complicated this can get. Because you can't sync git in git (nor any other SCM afaik).
I'm not sure I understand your point. My example is the "git" is WORK, you make changes on machine A, commit and push, then on machine B you git pull. Not really complicated at all. It just depends on "what" the OP needs to sync. If it's just data, lots of solutions, git, rsync, cvs, rcs, svn etc. If it's the entire machine including OS that is different and at least to me, raises the question "Do you really need to keep OS level in sync?". A lot of times the answer is no.

That's why I asked the question the way I did.
 
Keeping the basic software like editors/libreoffice in sync so that you use the same version on both machines - now that is a nice idea, but very hard to pull off. Hell, at one point, I tried to have same version of KDE on different machines. But no matter the amount of research I put in, no matter what I tried - that proved beyond me - for purely technical reasons.

Microsoft and Apple did pull that off - you can have the exact same version of Microsoft Office on two different machines, even if one runs win10 and the other runs win11. But - the downside was in the licensing terms that the big guys impose. In the Open Source camp, that same ability to run the exact same version of software - that proved to be impossible. So I personally accept that, because there's the upaside of not having the same license restrictions on the software as the big guys.
 
astyle Interesting point. For me, my editing is just text (code, writing quick start things, engineering cya papers) so "whatever version of emacs or vi is installed is fine". spreadsheets, formatted documents, agree that everyone either needs to use the same versions or have agreement on the minimum version.
 
astyle Interesting point. For me, my editing is just text (code, writing quick start things, engineering cya papers) so "whatever version of emacs or vi is installed is fine". spreadsheets, formatted documents, agree that everyone either needs to use the same versions or have agreement on the minimum version.
I think that this is what OP is angling for... But that's imposssible to know unless OP confirms.
 
  • Like
Reactions: mer
Incorrect, there are tons of git repos that get synced via git commands. Just look at Github.

I am talking about repo in repo which is not prohibited but that's what submodules are used for.

I'm not sure I understand your point.

Sorry I may've gone astray to scenario where whole home dir is under source control. You were speaking about just using git to track same version of work files.
 
  • Like
Reactions: mer
Sorry I may've gone astray to scenario where whole home dir is under source control. You were speaking about just using git to track same version of work files.
But even so, one can have subprojects in git. I have git repo for A (can be home directory or just a work thing). Under A I can have a git repo for B. (this is real life example from my $WORK). What happens is I do work in B, changes, testing, commits but it does not affect A. At some point I'm in A and want to pull in the changes from B. In git repo A I have done a "git clone B"; but in A, repo B is last time I did cd A/B && git pull. git status in A shows B is changed and needs to be comitted.

So whole home directory under git with things under home being git sub projects, one can change home directory and keep subprojects unchanged and others can change the subprojects without you pulling them into your home directory .

Confusing? Sure. Useful? Sure. But leads me back to "You must decide what you need. If you ask for help from 3rd parties, you must make clear what you wish to accomplish"

Me? I've always been "my data is the important piece"
Anyway, I'd like the OP to let us know more about the important pieces so we don't speculate.
 
But even so, one can have subprojects in git. I have git repo for A (can be home directory or just a work thing). Under A I can have a git repo for B. (this is real life example from my $WORK). What happens is I do work in B, changes, testing, commits but it does not affect A. At some point I'm in A and want to pull in the changes from B. In git repo A I have done a "git clone B"; but in A, repo B is last time I did cd A/B && git pull. git status in A shows B is changed and needs to be comitted.

So whole home directory under git with things under home being git sub projects, one can change home directory and keep subprojects unchanged and others can change the subprojects without you pulling them into your home directory .

Confusing? Sure. Useful? Sure. But leads me back to "You must decide what you need. If you ask for help from 3rd parties, you must make clear what you wish to accomplish"

Me? I've always been "my data is the important piece"
Anyway, I'd like the OP to let us know more about the important pieces so we don't speculate.
I'm not a fan of that approach. If I were in your shoes, mer , I'd put in the effort to keep private and work-related repos as separate as possible, to the point of having completely different repos, with different URLs for each purpose. Yeah, that's more work in some respects, but mixing personal and work-related stuff is just not a good idea.
 
I'm pretty happy myself with my own Nextcloud instance. My work machines may not be identical, but the bulk of my files lives in there and is readily available with native clients for everything I use. Pictures I take using my phone go there almost instantly, great for snapping diagrams off whiteboards and getting them on my desktop.
I've got a friend who swears by nextcloud, I need to try it out some time, it sounds useful.
 
Keeping the basic software like editors/libreoffice in sync so that you use the same version on both machines - now that is a nice idea, but very hard to pull off. Hell, at one point, I tried to have same version of KDE on different machines. But no matter the amount of research I put in, no matter what I tried - that proved beyond me - for purely technical reasons.

Just install the same package file on both machines? Trivial if you build yourself or you fish it out of pkg on one machine.
 
I'm not a fan of that approach. If I were in your shoes, mer , I'd put in the effort to keep private and work-related repos as separate as possible, to the point of having completely different repos, with different URLs for each purpose. Yeah, that's more work in some respects, but mixing personal and work-related stuff is just not a good idea.
Trust me I do. My example was really "work repo A that has work repo B as a subproject" but I extended it to what Zare was thinking of "my $HOME is a git repo that has other git repos as subprojects"

My $work stuff is done on $work systems ($work is linux I ssh from my FreeBSD to them), so yes separated.
 
Trust me I do. My example was really "work repo A that has work repo B as a subproject" but I extended it to what Zare was thinking of "my $HOME is a git repo that has other git repos as subprojects"

My $work stuff is done on $work systems ($work is linux I ssh from my FreeBSD to them), so yes separated.
Sorry, it looks like I confused $HOME with 'private repo that has has nothing to do with $WORK'... 😅
 
  • Like
Reactions: mer
Just install the same package file on both machines? Trivial if you build yourself or you fish it out of pkg on one machine.
If one machine gets the security patches on a regular basis while the other one does not (due to not being used very much, as per OP's scenario), at some point, they will just diverge too far to be able to accept each other's pre-compiled packages. And it really sounds like OP would prefer to avoid replicating the compilation efforts. Why else would OP look at syncing options and explore what's possible with them?

I think that OP probably has a wolf, goat, cabbage situation, and very well may end up doing something that is not an elegant solution at all - depending on what OP's goals and priorities are.
 
Back
Top