search

im-tomu / fomu-hardware

Tomu FPGA (Fomu for short), a FPGA which fits inside your USB port!
Creative Commons Attribution Share Alike 4.0 International
215 stars 22 forks source link

WIP - Rework the Fomu hardware directory structure. #9

Closed mithro closed 5 years ago

mithro commented 5 years ago

This pull request reworks the Fomu hardware directory structure which should fix #8.

It merges the evt, dvt and pvt branches into the archive directory.

xobs commented 5 years ago

Tags can work for linking to individual boards. We can start to favor tags over branches when linking to specific versions.

The reference directory is something that I use to look up information on a specific part. It can be very useful for sending information to the factory, or to look up alternate part options. I'd prefer to keep the documents around. Maybe one option would be to have a README.md in places such as prod/ that links to the various components that are in use?

Overall I'm happy with the direction this reorganization is taking.

mithro commented 5 years ago

Maybe we could have something like inuse and alternatives type thing?

mithro commented 5 years ago

Also as @ewenmcneill mentioned, have the identical files multiple times in the repository doesn't increase the repository size, so for windows people it's better to just copy?

xobs commented 5 years ago

Copying works as well. Have a unified reference directory and then make secondary "reference" directories for each of the projects (i.e. "hacker" and "prod")?

Having identical files multiple times in the repository doesn't increase the repository size but it should increase the checked-out size on all platforms, because only root can make hardlinks. But these files are likely small enough that the increase isn't noticeable.

ewenmcneill commented 5 years ago

only root can make hardlinks

FWIW, anyone can create hardlinks to their own files (possibly only root can create hard links to someone else files, but that's not relevant for a git checkout by the same user), eg macOS 10.14:

ewen@ashram:~$ cd /tmp
ewen@ashram:/tmp$ touch bar
ewen@ashram:/tmp$ ln bar baz
ewen@ashram:/tmp$ ls -il ba*
12896555163 -rw-r--r--  2 ewen  wheel  0  8 Jul 15:33 bar
12896555163 -rw-r--r--  2 ewen  wheel  0  8 Jul 15:33 baz
ewen@ashram:/tmp$

and Debian Linux 9:

ewen@debian:~$ cd /tmp
ewen@debian:/tmp$ touch bar
ewen@debian:/tmp$ ln bar baz
ewen@debian:/tmp$ ls -il ba*
918074 -rw-r--r-- 2 ewen users 0 Jul  8 15:37 bar
918074 -rw-r--r-- 2 ewen users 0 Jul  8 15:37 baz
ewen@debian:/tmp$

However, yes, the checked out version of the repository will contain duplication of the files contents (except maybe on macOS on APFS and other filesystems which have magic dedupe around file copies and/or copy-on-write semantics).

I tend to agree that the files aren't big enough for that duplication of the file contents to be an issue, and the convenience of having the reference files checked out in both places one would want to look for them is definitely worth it.

Ewen

mithro commented 5 years ago

So.. What is the next step. Shall we merge this and then continue?

xobs commented 5 years ago

Yes, let's merge this for now, and then continue from there.

mithro commented 5 years ago

Done!