[Oberon] http://cas.inf.ethz.ch/projects/a2

[Michael Schierl]

Hello Felix,
Hello P.L.,

Am 04.11.2022 um 08:13 schrieb Felix Friedrich:

> * SVN allows for a more fine-grained user management. This has become
> less important meanwhile in this context, so that is not a large issue
> any more. If in doubt, a separate git repo can be created for private
> projects.

Or, one can use git submodules, which are effectively a repo on their
own that is linked by commit hash to the parent repository, but appears
like a subdirectory. Still, anyone who commits there without commit
rights to the parent repo will need to make a PR to the parent
repository so that the changes become visible in the parent repo.

But yes, in general when you need more fine-grained control, either
create more fine-grained repos or switch to a pull request based model.

> * A GIT checkout contains all history and will probably become huge for
> A2 with all its binaries. Maybe there is a way around this, I am not sure.

Several. One is replacement references (aka grafts). They specify in the
repo metadata that if you have a commit with hash xyz, it should be
treated as a replacement for a commit with hash abc. So your main branch
has a more shallow history (e.g. only shorter time frame or no history
for some directories), and there is a full-history branch. When you
pulled that branch, your git will magically behave as if your main
branch also has full history.

Another option would be submodules again. Have sources/ as a submodule,
so those who (like me) only care about the history of the sources, not
of the binaries, can checkout only the submodule repository and extract
it alongside some binary artifact that contains the binaries for their
platform. Anyone who cares about history of all the binaries as well
will checkout the full repository (which also contains the submodule's
content up to some point and then switches to use the submodule).

The main drawback with those approaches is that some clients will not
fully support those features. as long as you are using the official git
client, that won't be a problem though; and you can always work with the
repos as if they were not submodules.

The most pragmatic approach would be to get rid of the binaries in
source control altogether.

> * I personally like svn with its linear version numbers, otoh git is
> much more flexible with its branching capabilities.

Assuming that you have a single source that decides which version comes
when, linear version numbers are of course nicer.

> When/if we do the switch, I will try to preserve all history of the A2
> SVN in git and / or leave the SVN (read-only) in place.

Yeah, good :)


peter at easthope.ca wrote:

>>From the page cited above:
> "Git's repository and working directory sizes are extremely small when
> compared to SVN."

Note that this is only true as long as you follow git's preferred
workflow and store only sources and not binaries in the repo. Git uses
some clever diffing and compression tricks that work fine with text
files that gradually change and less well with binaries that make large
progressive changes. (SVN stores all uncompressed pristine copies of the
current revision in the working directory, which usually compress to a
fraction of their sizes even when using something like gzip to compress
them. Then it is easy to "add some history" and still stay smaller than
SVN).

But probably one has to try. <https://github.com/metacore/A2OS> is a
GitHub mirror of the A2 repository trunk (it contains revisions from
6323 to 10263, i.e. history back to August 2015) and the .git directory
size is 1.3 GiB. My partial SVN checkout of the A2 repository (only ocp,
tools, source, Win64) comas with a .svn directory of approximately 280
MiB. Adding about 250 MiB of working copy size to both of them (assuming
I am checking out the same parts into the working copy with Git as with
SVN), th Git repo is still three times as large as the SVN repo and only
provides access to a fraction of the history.

On the contrary, running git-filter-repo on the A2OS repository, keeping
only (history of) source directory, results in a repository size of 46
MiB. Which is about half of the size of the current source directory.


Regards,


Michael