AD18 and Git - Page 1
Forum section: electronics / general

author: Pack34
author_rank: Frequent Contributor
timestamp: December 20, 2017, 01:12:41 am
content: I remember that one of the initial rumors of AD18 was that it had Git support. Did this actually happen?

author: Gibson486
author_rank: Frequent Contributor
timestamp: December 20, 2017, 04:44:55 pm
content: Does it really matter? Unless you use the vault, it is basically one extra step you have to do.

author: Pack34
author_rank: Frequent Contributor
timestamp: December 20, 2017, 06:43:47 pm
content: If it does, then there should be a way to integrate it with a Bitbucket or Github repo

author: voltsandjolts
author_rank: Unknown
timestamp: December 20, 2017, 09:32:29 pm
content: https://www.eevblog.com/forum/altium/altium-designer-18-info/msg1355082/#msg1355082

author: Gibson486
author_rank: Frequent Contributor
timestamp: December 21, 2017, 05:07:48 pm
content: Quote from: Pack34 on December 20, 2017, 06:43:47 pmWell, if it is going to be anything like integration with SVN, it does not really help unless you are going to use the Vault. In my case, when I tried SVN through Altium, the files never showed up on other people's computer. We never found out why, but it was never really worth the hassle of figuring it out since there was no benefit (we did not use the Vault).Using TortiseSVN to commit was not a hassle at all.

author: Pack34
author_rank: Frequent Contributor
timestamp: December 21, 2017, 11:05:26 pm
content: Quote from: Gibson486 on December 21, 2017, 05:07:48 pmIt looks like we're going to have to keep using Sourcetree. I just thought it would be nice if it was integrated. Doing your commits and everything through AD18 instead of using a separate program. Not a big deal.

author: olkipukki
author_rank: Frequent Contributor
timestamp: December 22, 2017, 03:46:23 pm
content: Quote from: Pack34 on December 20, 2017, 01:12:41 amYep, happened finally.I started to use Git for AD projects in pre18 version era, not only for PCB designs, but handle related stuff (PDF datasheets, specs & docs, STEPs etc.) as well. Taking into account that BitBucket supports LFS now, you can include everything in one place.Just tried to open a project in AD18 and it recongnised my git repo, so can commit and push changes to a remote without any issues in AD18.As for me, real benefit is ability to add commit comments from UI rather than switch to a git external tool, I will keep use custom push scripts across all repos as is.

author: valtor
author_rank: Newbie
timestamp: January 02, 2018, 02:09:05 pm
content: Hi olkipukki,Any chance you could detail your steps of how you set up git/bitbucket within Altium 18? There is next to no info on the Alitum website about git, I got no search results...Many thanks!

author: tszaboo
author_rank: Super Contributor
timestamp: January 02, 2018, 02:56:23 pm
content: There isnt any benefits in git over SNV for PCB. Stop thinking like a programmer, and just use SVN.

author: olkipukki
author_rank: Frequent Contributor
timestamp: January 03, 2018, 05:07:15 pm
content: Quote from: valtor on January 02, 2018, 02:09:05 pmHi valtor,You will need setup a git repo locally and AD will pick up these settings (as well as any git client and how it would be)In other words, I did nothing special for git-AD integration.Do you have any experience with git?P.S.Found a bug - you cannot add & commit a new (not in repo) individual file, but can via 'Commit Whole Project...' option

author: olkipukki
author_rank: Frequent Contributor
timestamp: January 03, 2018, 05:12:42 pm
content: Quote from: NANDBlog on January 02, 2018, 02:56:23 pmYep. In general, AD local history and remote SVN server might be enough...

author: alexwhittemore
author_rank: Frequent Contributor
timestamp: March 07, 2018, 01:25:00 am
content: Quote from: NANDBlog on January 02, 2018, 02:56:23 pmI totally disagree!Let me rephrase your statement: there isn't any benefit to using SVN over git for PCB work (or Altium projects, more generally).Unfortunately, both are rather poorly suited to Altium projects, since most of the files are a binary format that doesn't give you any info whatsoever just to look at it in a repository browser. To get anything out of either of them, you have to be pretty aggressive with commit messages and comments, which basically no hardware designer I've ever met is. But the advantage is HUGE when you realize there's a design defect or anomaly and you need to figure out how, when, and why it got there.And SVN and Git use totally different philosophies for how and where to store data, so the advantages of one over the other really have little at all to do with what kind of project you're controlling and much more to do with your workflow. Personally, I find it WAY easier to move through projects with Git over SVN, for a whole bunch of reasons, even if you leave behind the fork/pull request model that software devs often employ for code review reasons (and which breaks terribly when your main design files are binary).Of course, there's mostly no advantage to using an altium-internal interface rather than something like sourcetree or command line. The only real reason I want a built-in git client is for easier comparison between revisions (rather than having to go extract a copy of the old manually, then open both manually, then compare). I guess having source control status on each file in the list is ideal, too.

author: voltsandjolts
author_rank: Unknown
timestamp: March 07, 2018, 09:42:28 am
content: My employer has a NAS running SVN. That is a pain when working away from the office - can't make commits.AFAIK GIT allows 'local commits' where you can make commits on your own machine and then re-sync with the NAS GIT repo sometime later.Is that correct? If so, that's a tempting feature for me.

author: hscade
author_rank: Contributor
timestamp: March 07, 2018, 09:47:21 am
content: Quote from: voltsandjolts on March 07, 2018, 09:42:28 amYes, that it how decentralized systems work.

author: tszaboo
author_rank: Super Contributor
timestamp: March 07, 2018, 11:16:39 am
content: Quote from: alexwhittemore on March 07, 2018, 01:25:00 amOf course there is. Altium supports SVN natively. It has built in support. From the project window, you can see what is up to date, what has been changed, and even compare to older revisions.http://www.altium.com/documentation/15.1/display/ADES/((Using+Version+Control))_AD"The key to locating and viewing the comparison differences is in the Differences panel, which provides a selectable list of the logical or graphical differences between the documents. The panel's listed entries for each document revision interact with the editor, allowing a detected difference (such as a moved component) to be graphically highlighted when selected."Doesn't matter, that it is binary.So again, use the damn tool as it is meant to be used.

author: alexwhittemore
author_rank: Frequent Contributor
timestamp: March 07, 2018, 06:09:48 pm
content: Quote from: NANDBlog on March 07, 2018, 11:16:39 amNo, not when using a different toolchain means I can move much faster and more precisely.Also, what a dumb philosophy. "Do with what you have and never demand better tools!" Do you still lay out your boards with black tape?

author: tszaboo
author_rank: Super Contributor
timestamp: March 07, 2018, 08:37:08 pm
content: Quote from: alexwhittemore on March 07, 2018, 06:09:48 pmLet's see:SVN: Works.Git: Doesnt workProgrammer concludes git is better.Well good luck then.

author: alexwhittemore
author_rank: Frequent Contributor
timestamp: March 07, 2018, 10:24:13 pm
content: Quote from: NANDBlog on March 07, 2018, 08:37:08 pmDefine "Works," though. You can do (I'd argue, more easily) every version control function outside of the built-in client, including diffing. The only disadvantages are that you don't see live version status inside AD, and you have to click a few more times to diff arbitrary versions. Given that slight disadvantage, I argue that git has a ton of actual-vc-stuff advantages over SVN. And of course, now there's support for it, so I'm certainly not the only one.

author: andyturk
author_rank: Frequent Contributor
timestamp: March 15, 2018, 03:34:12 pm
content: Quote from: NANDBlog on March 07, 2018, 08:37:08 pmActually, git works reasonably well with Altium.We keep our hardware design in the same repo as our firmware. That makes is very easy to associate the right fw for the right hw across board spins. Gerbers and generated .pdfs go in the repo too. If you can pull the repo (using whatever GUI you want), you can get *everything*.The main issue I have using git with Altium is that there's no way to merge library changes. E.g., I've got a pcb library with footprints I need to share across multiple projects. Using a typical "git flow" model, I create a feature branch, and then make some changes to that library. With C code, it's super easy to merge changes from a feature branch back into master. But git doesn't understand how to identify only the components I modified in an Altium library (since it's a binary format), so it has to take the entire library from my branch as what ends up in master. So if someone else is also modifying the same library, whoever merges last obliterates the other person's changes.Does SVN allow two people to modify different components in a shared library and easily merge those changes? (Honest question... I know nothing about how SVN works)

author: Bassman59
author_rank: Super Contributor
timestamp: March 15, 2018, 05:51:10 pm
content: Quote from: andyturk on March 15, 2018, 03:34:12 pmAltium libraries are binary files, which cannot be merged, so it's a good idea to require that they have the svn needs-lock property on them. With this, before you edit the file in your working copy, you must obtain a lock from the repository. If you use TortoiseSVN, it's a simple matter of right-clicking on the file and choosing "Get lock ..." from the context menu.Order of operations:a) Update your working copy of the library so you get the latest changes.b) Get a lock on the file. This prevents someone else from committing their changes to the repo.c) Make your changes. Commit to the repo. This releases the lock.TortoiseSVN enforces a rule that files which require locks cannot be edited by marking the file as read-only in the file system until a lock is obtained. This prevents you from editing a file that you can't commit.SVN's locking prevents you from making changes to a file you cannot then commit. But it requires that you talk to the other users who are allowed to edit files and commit them back to the repository.

author: Gibson486
author_rank: Frequent Contributor
timestamp: March 21, 2018, 01:47:15 pm
content: At the end of the day, SVN and git are the same thing for PCB stuff. You commit and upload. I am not sure what the argument is about. In most cases, you are limited to what your employer does. As someone mentioned, you need to be very descriptive about your changes since both are binaries that means nothing when you read them in most cases. As for integration, once again, the argument is only valid if you use the vault. if you do not use the vault, integration only saved you 20 seconds worth of time.

author: Gibson486
author_rank: Frequent Contributor
timestamp: March 21, 2018, 01:58:03 pm
content: Quote from: andyturk on March 15, 2018, 03:34:12 pmSVN works the same way. With KiCAD, it was easier to fix because the files were simply ascii files that could be read, so you can track the changes and merge. However, I do not really recommend KiCAD for big teams because everything is always referencing your main libraries, so if you made a change without realizing it, you could have changed the part in multiple files on past projects. It is just too risky.Back to your issue. If you find a conflict when you merge, you need to hash it out with the parties involved anyways. You do not just blindly merge stuff or replace. with Altium, merging an actual library file is difficult because the file is binary that is readable only by Altium (at least from what I saw). Perhaps with SVN or git integration, that could be fixed. But that is not what I saw when I used it (keep in mind that I only used the internal SVN module for about an hour and stopped because it just lead to fustration).At the end of the day team design takes a lot of discipline. Git or SVN will not change that.

author: JacobEFOvergaard
author_rank: Newbie
timestamp: June 25, 2018, 06:26:16 pm
content: Well actually Git works rather well. The internal VCS system works with Git the same way SVN works.So by using Altium's own VCS "gui" you can access the schematics of the earlier commits and have them shown live, with messages designating differences as well as highlighting, just as you can with SVN.So no doubt about it, I definitely switched to Git instead of SVN.

author: julianhigginson
author_rank: Frequent Contributor
timestamp: June 27, 2018, 01:57:42 am
content: the only sane way to work around having independent user operated part libraries in a version control system is to have part libraries that only contain one part each.YES it's a bit of a pain, but it means in a morning you can create library parts for a new ADC, someone else can create library parts for a new processor and an I2C eeprom, and someone else can correct pin numbering errors they discovered on a LED footprint, and the results can easily and simply get merged as people just commit their work.

author: JacobEFOvergaard
author_rank: Newbie
timestamp: June 28, 2018, 08:12:59 am
content: Quote from: julianhigginson on June 27, 2018, 01:57:42 amI am exactly in the middle of this. Making an "internal library" and I am not yet sure, how it is best solved. This library is to be used by a small university group, and it is important people can easily add and change footprints, while keeping track of changes.My initial thought was to have ALL components as a integrated library, one library for each component.But that would mean you have to "install" say 1000 integrated libraries in Altium, seems insane to me. Or am I missing out on something here?

author: julianhigginson
author_rank: Frequent Contributor
timestamp: June 28, 2018, 10:02:24 am
content: you should be able to have lots of schlib and pcblib files in an integrated library project?not 100% certain but it'd be fast to try.I use a dblib now. so I just have a single DBlib file, with the separate library files in a folder structure "below" that, and the dblib file points to a database (previously excel file, now migrating to SQL) which has a record for each part, that links to the schlib and pcblib files each part in the database needs, in reference to their location from the dblib file.

author: Gibson486
author_rank: Frequent Contributor
timestamp: June 28, 2018, 01:56:12 pm
content: Quote from: JacobEFOvergaard on June 28, 2018, 08:12:59 amEach library can contain multiple parts. So, in your resistor library, you have a specific 10K resistor as a single part, which is probably designated by a vendor part number. You do not really turn it into an integrated library until your are sure it will not change. In my environment, I do not even bother with the integrated library. The thing is, if you work in a heavily regulated industry, the steps will seem absurd, but they will be required by your internal regulatory group. If that means you will have thousands of integrated libraries in your platform, then that is what it means.

author: JacobEFOvergaard
author_rank: Newbie
timestamp: June 29, 2018, 08:13:33 am
content: Quote from: Gibson486 on June 28, 2018, 01:56:12 pmAh then I simply misunderstood the point. I thought every single component should be ONE integrated library itself. Right now I am also making it with an integrated library for say resistors. However the thing I find hard to deal with here is, if two people change something in the same integrated library. We will not be able to easily see which part of the integrated library was changed.Initially we are handling the library on GitHub, at least until we can try out the Altium Vault.