Go Down

Topic: what do y'all use for version control? (Read 776 times) previous topic - next topic

Robin2

I'm a big believer in version control.
This is not a complaint or a criticism. And I am not expecting a Reply or an attempt at further explanation.


When I read through your Reply #13 almost none of it is meaningful to me. There is clearly some high-level concept in your head that I have never managed to get into mine :)

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

jimLee

Ok, since were on the subject.

What's the best way to set up repositories? Right now I have one big one basically everything Arduino. I'm wondering if the idea would work better if I had one per library folder that I own/manage?

-jim lee
PNW Ardiuno & Maker club
1012 9Th Street, Anacortes, WA 98221 (Around the back of building)

Coding Badly

#17
Jan 12, 2019, 09:20 am Last Edit: Jan 12, 2019, 09:21 am by Coding Badly
I'm wondering if the idea would work better if I had one per library folder that I own/manage?
One repository for each project is ideal.  Each project should be a logical group of files.  "Everything Arduino" is not a logical group.  "My Weather Station" is a reasonable logical group.

Smaller project specific repositories allow you to make the best use of branching, tagging, and merging.

Larger multi-project repositories make it difficult to manage branches / tags and impossible to merge.


pert

When I read through your Reply #13 almost none of it is meaningful to me. There is clearly some high-level concept in your head that I have never managed to get into mine :)
I had a similar reaction to all the Git tutorials I tried. As a hobbyist, I just wasn't that dedicated to learning the topic from the foundations. So I gave up on that and just started using it, first via the simplified and limited GitHub web interface, then on to the slightly more powerful GitHub Desktop. Instead of learning Git just for the sake of learning Git, I was able to get hooked on this incredibly useful tool with very little effort, then learn what I needed in little bits as I went along. For a professional, this is probably not the efficient way to do it. But for someone like you who is having trouble seeing the benefits of moving on from caveman-style version control, I think it would be a good path.

pert

I'm wondering if the idea would work better if I had one per library folder that I own/manage?
Much better. The mega-repo approach is going to lead to a messy commit history that's impossible to follow. The only reason I you should even consider doing something like that is if I was working with multiple libraries that are closely coupled, where a change to one often requires a change to the other in the same commit. Even then, it's a bad idea because the ideal Arduino library repository is to have a single library in the root of the repository. That makes it easy to install. It's also required if you want to add your library to the Library Manager index. All the official Arduino libraries are structured this way. The 3rd party Arduino repositories that are not structured that way are a frequent cause of confusion for beginners. Prime examples being:

Robin2

But for someone like you who is having trouble seeing the benefits of moving on from caveman-style version control, I think it would be a good path.
I do appreciate your suggestion (which is a sensible idea) but my problem is that I can't see any benefit in even that amount of effort when all my programming is for me on my own.

I guess I don't like the idea of getting drawn piecemeal into a "cult" that I don't understand.

Maybe another thing that "frightens me off" is the notion that I have to commit (pun intended) myself 100% to the system or it's not worth the effort.

And the piece of code that I suddenly realize I would like to go back to is the only one that I did not save (or commit) :)

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

bperrybap

Ok, since were on the subject.

What's the best way to set up repositories? Right now I have one big one basically everything Arduino. I'm wondering if the idea would work better if I had one per library folder that I own/manage?

-jim lee
It depends on what you are wanting to accomplish.

While you could put it all in one repo, my general rule of thumb is that if there are blobs or "entities" that are or could be separate components, then make them separate repositories.

Having them in one bundle can be convenient to grab everything at once, but having them separate, allows better source control of things like revisions. When they are separate you can track and create separate release tags for each component  / library.

git is about versioning a directory tree or collection of files, not individual files. The issue you can run into if everything is one repo with something like libraries, is that you can not selectively checkout different versions of each individual library. You are stuck checking out the entire blob for a given point in time.

Even if they are separate repositories you could use submodules to create a wrapper repository that pulls in other repositories to create your desired directory structure.

And if you ever want to publish your Arduino libraries to be part of the Arduino IDE library manager or automatically pulled into platformio or libraries.io you will need to have each library in its own git repository.

I'm also a big believer and user of automation for doing builds and creating releases.
For example, for things like Arduino libraries, I use scripts that can pull revision tags from git and automatically update the library.properties file, header files, and documentation and recommit the files and re-tags them when I do a release.
It ensures that everything is consistent with the proper release information and makes doing releases really easy.

--- bill

bperrybap

I do appreciate your suggestion (which is a sensible idea) but my problem is that I can't see any benefit in even that amount of effort when all my programming is for me on my own.
This sounds more like you are not using or not wanting to use any source control vs not wanting to use git.
From a very high level git is really not that much different than other source control systems.

The benefit to using version control and having tools like diff and meld is that with with a command line or a GUI you can see what has changed or has been modified and potentially commit the changes or revert them.
Using a source control tool means you don't have to have multiple directories laying around for working on modifications or keeping old copies around that you can revert back to. That is all done by the tool.
And with tools like git you can push your updates to a git cloud service like github which helps protect you from losing the files should something happen to your machine or your backups.

Using source control tools can save time. It allows you to create a history of your changes and gives you the ability to checkout any version of the s/w you have committed.
It is part of a good development practice.
I can't imagine doing any s/w without having revision control and tools like diff and meld.

If you use the file manager plugins, it really is as simple as a few clicks to do things in a tool that you are more than likely already using, and the file manager colorizes and changes icons on the files to indicate their status.

--- bill


westfw

Ah.   The MOOC that I had found useful was on Udacity (one of the free classes.)
https://www.udacity.com/course/how-to-use-git-and-github--ud775

pert

I do appreciate your suggestion (which is a sensible idea) but my problem is that I can't see any benefit in even that amount of effort when all my programming is for me on my own.
If you install GitHub Desktop and start using it on one of your projects, the benefit you'll see immediately is commit messages. You make a change to your code and save the files. Then you commit those changes with a commit message that notes the reason for the change. It's so incredibly helpful to have that note to yourself for every change so you can look back through the commit history "Why did I do that? Oh, I see!".

You'll also get a very quick and convenient diff view of the changes in each commit. Sure, you can do that with your current system, but not in a way that allows you to quickly browse through the history of changes.

Those benefits easily make the minimal initial investment of time and energy to get started worthwhile. Over time, you'll decide it's worth making additional small investments to learn additional features as you need them, and these investments will also be worthwhile. There are features of Git that you'll have no interest in, so you simply don't waste time learning about those until such time as you might have a need for them.


I guess I don't like the idea of getting drawn piecemeal into a "cult" that I don't understand.
You already understand the need for versioning, otherwise you wouldn't have done the work to set up your current system. So the only thing you need to accept is that a formal system for doing version control might be better than the one only you are using. Then give it a chance. You can continue using your current system at the same time.

Cults prove that groups of people can be utterly wrong; but it's stupid people who participate in cults. Huge numbers of incredibly intelligent people are using Git and similar systems. Can you really believe they're all just drinking the koolaid?

Robin2

#25
Jan 12, 2019, 05:37 pm Last Edit: Jan 12, 2019, 05:38 pm by Robin2
Cults prove that groups of people can be utterly wrong; but it's stupid people who participate in cults. Huge numbers of incredibly intelligent people are using Git and similar systems. Can you really believe they're all just drinking the koolaid?
I didn't mean that the people using GIT are members of a cult. Merely that the concept of version control (and not just Git) seems to me as mysterious as a cult. I can see how it is probably essential when a group of people are working on the same project.

I get the feeling all the time that people are telling me all about the gear wheels in a clock without telling me about the clock :)

And thank you for your input.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

jimLee

#26
Jan 12, 2019, 08:12 pm Last Edit: Jan 12, 2019, 08:15 pm by jimLee
Ok, lets see I have a few larger sketch projects, mp3 player & the cellPhone would be examples. And a bunch of other mess about sketches. Then, on the library scene, I have.. LC_baseTools as the foundation toolset for everything, LC_screen the foundation toolset for all drawing, and a bunch of other libraries for this and that general purpose functionality.

How would you set up repositories for a set like this?

-jim lee


PNW Ardiuno & Maker club
1012 9Th Street, Anacortes, WA 98221 (Around the back of building)

pert

A separate repository for each sketch and each library.

bperrybap

#28
Jan 12, 2019, 08:52 pm Last Edit: Jan 12, 2019, 08:55 pm by bperrybap
A separate repository for each sketch and each library.
I agree.
For my own Arduino stuff, I always create a "sketches" directory under my sketchbook directory where all the sketches are placed.
Then I create or clone each repository for a library into the "libraries" directory and for each sketch into the "sketches" directory.
If using a file manager addon, you can easily see what projects have uncommitted changes in them by simply going into
the libraries or sketches directory by looking at the icons for the directory/folder. Then go down into the desired one and you can see which files, then right click on the specific file and bring up a diff/meld that shows the specific changes in that file.

And if you don't already know, the Arduino IDE will locate sketch files no matter how deep under sub directories under the sketchbook directory. So you can organize your sketch repository tree any way you want and still use the IDE for builds.

--- bill

Delta_G

#29
Jan 12, 2019, 10:35 pm Last Edit: Jan 12, 2019, 10:44 pm by Delta_G
Here's my main screen that I work in on Eclipse (Oxygen.2 on Ubuntu 16 I like to stay a few versions old for stability).  At the bottom are a bunch of tabs I use.  Here I'm showing the Git Staging tab which shows what files have uncommitted changes. 




This page is real nice because I can ignore any files or add them to the repo or all of that at the same time.  Click and drag them down to staged area and hit Commit or Commit and Push(to send it to github).


It throws up this dialog to show what it did.  And blammo.





I use github less to keep up with versions or share code with others.  That's more of a side benefit.  I mostly use it because I have different computers that I work with the same code from and as long as I'm disciplined about committing and pushing whenever I get done on one of them then the pull on the other computer is a simple "fast forward" and it all works out seamless. 



The other screen that is cool is the Git Repositories pane.  This is where you can check out a branch.  Often I might want to work on something to do with the motors while I am at home and can test and then I might want to tweak on gui code or something on the laptop with just an Arduino and the LCD while I'm out on the road.  So I can have multiple branches where I work on multiple things without breaking code on other parts.  When something is complete and working I can merge it back into the master branch so it always has complete and working code. 





And finally the coup de gras, the Git Reflog view. 

Now when I code myself into a corner I can back up to a known point based on a known commit.  I can even rebase and then merge the changes back in selectively except for the part I want to undo.  And when I have to take a long few months break from the project I can come back and follow the commit messages and pick back up what I was working on.   It's nice to have that, "oh yeah that's why I did that" moment.





|| | ||| | || | ||  ~Woodstock

Please do not PM with technical questions or comments.  Keep Arduino stuff out on the boards where it belongs.

Go Up