Version Control System Which Keeps Track of Individual Files

Version control system which keeps track of individual files

I agree with @BasileStarynkevitch -- Git is all you need .

You probably only need a nice GUI for Git , so you can more easily see what's going on.

Git is made for programmers, to handle large amounts of source files, spread over multiple sub-directories.
Your use-case is slightly different, but you can still use Git nicely for it.

Early version control systems (RCS, SCCS) did what you just described in your question -- but it proved to be a mess, because any real project has typically more than just one file ;-) and it's easy to forget to check in a file if each one is handled by it's own version control. (don't do this)

So instead of thinking "I need to get the previous version of file A, and another version of file B" , try to think of making snapshots in time of your complete project when you use Git. e.g. "mini-releases" of your project. If your project is LATEX, then you are writing a book or publication - maybe check-in your changes every time you're done with an update, and think of this as a 'mini-release' ..

Using a Graphical User Interface for Git will help you see the differences between files, branches, tags, etc..
Git has features for merging-in content from earlier versions of a file into the current file -- so that is not a problem with Git. There are also tools for viewing and editing side-by-side diffs.

Version control for other kinds of files? (non-source code files)

git is deliberately stupid. its' so dumb it's named for being dumb.

Git is so dumb that it doesn't know or care what format the files it tracks are using. It doesn't know how to fix them in a merge if two people edit the same file. (actually, it is that smart for a lot of types, but that's actually an extra module that is independent of the version tracking feature)

but it is smart enough to prevent you from overwriting changes when they do diverge. And it will also tell you who is to blame when that happens.

git doesn't manage a central repository, there's no such concept. in git, each person making changes has the complete repository on their local machine, and they pass changes to and from one-another. You can 'fake' a central repository by passing a change to an officially 'blessed' repository, on some convenient server.

So how does any of this answer your question?

Is there any kind of system or architecture/protocol that could be put in place to establish version control for non-source code files of any arbitrary type, in any arbitrary networked/shared directory? [Running on Max OSX network]

Or any ideas how to prevent people from making changes to files that other people might be working on?

Git doesn't know or care what format it's tracking. It treats all files the same. What you really seem to be concerned about is preventing one person from clobbering all over the changes of another person.

Git sidesteps that issue entirely. There is no official copy to clobber. If you are using a centralized server, and one user tries to push over a change that would overwrite a more recent change than that user has seen, the push fails. The user has to pull the new version, resolve the changes/conflicts and try again. Even if a user stubbornly just drops the old change on the floor and uploads his own without regard to the changes that occurred between his first pull and final push, no data gets lost, because git keeps everything, and a more responsible individual can cherry pick those files and fix it.

VCS system to keep track of graphic and asset files with Python?

I use Subversion on a Ubuntu 20.04 64 bit OS at home. I have Apache web server running with the webDAV setup and that allows me to use Subversion through a browser or use http to access my subversion repository from a Windows 10 machine using Visual Studio and the ankh subversion plug-in.

Works great. There are other possibilities such as Mercurial. Really kind of depends on your goals and the organization.

I went this way after doing something similar for a small team at a university running Ubuntu with Subversion and Apache on a Linux virtual machine on the university network for two different teams on two different projects with one team of some three people and the other team with about 5 people.

See enabling Subversion access via Apache web server and DAV on Ubuntu

I see mentions of an open source version control system Boar that looks to be in python and handles large binary files. The source seems to be on GitHub and they would probably be happy to have help. See https://github.com/mekberg/boar

For binary files see the following:

Do version control systems use diffs to store binary files?

How do different version control systems handle binary files?

Version control for large binary files and >1TB repositories?

Binary Delta Storage

See also Git FAQ: Handling Large Binary Files with LFS

Large binary files are a tough problem for every version control
system: every little change to a large binary file will add the
complete (large) file to the repository once more. This results in
huge repository sizes very quickly.

The "Large File Storage" extension for Git deals with exactly this
problem.

You can also set up your own Git server. See How to Set up the HTTP Git Server for Private Projects

One possibility is the HTTP Git Server. This open source project uses
NGINX to serve up Git repositories over your Local Area Network (LAN).
HTTP Git Server is surprisingly easy to setup and manage.

I’m going to walk you through the process of installing and
configuring HTTP Git Server on Ubuntu 18.04. Once complete, you’ll
have a repository that anyone on your LAN can use.

How should I start with tracking file changes/versions?

It's seems to me that github is prefect choice for your requirement. You can create repository for maintain the history, it's easy to use and it is free

https://github.com/

How are version control histories stored and calculated?

You mentioned these 3 methods of storing (file)-history:

1. patch : a patch is the (usually textual, but binary patches are also possible) representation of the difference between two files. It is the output of unix command diff and can be applied by unix command patch. A lot of versioning systems are using patches to store the history of files (eg. SVN, CVS, GIT..). Sometimes these patches are technically called "delta" as the greek letter "Δ" describing the difference of two things.
2. changeset: a changeset is a term to combine changes "which belonging together" to different files in a single entity. Not all versioning systems support changesets (most notable CVS and SourceSafe). Developer are using changesets to avoid broken builds(example: change the signature of a method in one file, change the call in a second file. You need to have both changes in place to run the program, otherwise you get an error).
   See also here for the difference between changeset and patch.
3. snapshots: are full copies of the state of this file/filesystem to this point of time. They are usually quite large and their usage depends on performance characteristics. The snapshot is always redundant to a list of patches, however to retrieve information faster, sometimes Versioning Systems mix or combine patches and snapshots

Subversion uses forward deltas(aka patches) in FSFS repositories and backward deltas in BDB Repositories.
Note that these implementations have different performance characteristics:

• forward deltas are fast in committing, but slow on checkouts(as the
  "current" version must be reconstructed)

• backward deltas are fast in checking out but slow on commit as new
  deltas must be constructed to construct the new current and rewrite the previous "current" as a bunch of deltas

Also note that FSFS uses a "skipping delta" algorithm which minimizes the jumps to reconstruct a specific version. This skipping delta however is not size optimized as mercurials snapshots; it just minimizes the number of "revisions" you need to build a full version regardless of the overall size.

Here a small ascii art (copied from the specification) of a file with 9 revisions:

0 <- 1    2 <- 3    4 <- 5    6 <- 7
0 <------ 2         4 <------ 6
0 <---------------- 4
0 <------------------------------------ 8 <- 9

where "0 <- 1" means that the delta base for revision 1 is revision 0.

The number of jumps is at most log(N) for N revisions.

Also a very pretty effect on FSFS is that older revision will be written only once and after this they will be only read by further actions.
That's why subversion repositories are very stable: as long as you do not have a HW failure on your harddisk, you should be able to get a working repository even if some corruption occurred in the last commit: You still have all older revisions.

In BDB Backend you have constantly rewrite the current revision on checkins/commits, which makes this process prone to data corruption. Also as you store the full text only in current revision, corrupting the data on commit will likely destroy great parts of your history.

How to I keep track of changes in FLA file (via version control)

Flash CS5 has introduced a new file format called XFL which has been designed for use with version control systems. This format basically splits up your FLA file into a series of separate XML data files (all contained within the one folder) which means version control systems can accurately determine what parts of the file have changed.

Simply go to File > Save AS, and select xfl from the drop-down list.

If you're using anything before CS5, then unfortunately there is no similar way to accomplish this task. I will add, however, that if this is the case, then you can try and mitigate this problem by keeping all your code in an external AS file and load any data from external xml/image/etc. files. This way, there is at least some degree of tracking for certain parts of your project.

Best version control system for managing home directories

I've had the same problem, and built a tool on top of Subversion that adds permission, ownership and secontext tracking, keeps the .svn directories out of the actually versioned trees, and adds a concept of layers so you can for example track all your config related to development, which you then only check out on machines you use for developing.

This has helped me organize my settings much better across the 50+ machines I log into.

Here's the project page. It's still a little rough around the edges, but we also use it at work to version system configuration for our 60+ servers.

In general, any version control system that uses some sort of metadata files to track stuff is going to cause you pain as is when actually using it.

Choosing version control system

For multi-site development, a DVCS (Distributed Version Control System) is actually recommended because it allows:

• private commit
• "backup" publication (you push your branch which will then be mirrored in the remote repo, still as your branch: nobody will be impacted)
• common publication: you push a common branch (which you have pulled first to take into account other commits)

That publication workflow (orthogonal to branching) really opens more possibilities in term of code management.

Pick one (Git, Mercurial, ...) and you have a valid solution to your issues.

---

Related Topics