pijul_org / pijul

#365 Bare repositories

Opened by lthms, on March 6, 2019
Open
Feature
Good first bug
lthms commented on March 6, 2019

It would be nice (for self hosting purpose) to be able to create so-called “bare” repositories (at least that is how git calls them), where the content of the repository is not output.

lthms added tag
Feature
on March 6, 2019
pmeunier commented on March 6, 2019

Yes, but why? Git needs bare repositories because it doesn't handle patch commutation, and so cannot handle edits to the working copy in parallel with a push. That seems like an antifeature to me.

lthms commented on March 6, 2019

Well, I think I recall you saying once the Nest was not outputing its repositories because, well, there is no need for that server-side. That is basically the same thing here.

lthms commented on March 10, 2019

So, just to try being clearer, I personally would love to have this feature for several reasons:

  • Having a kind of repositories where patch cannot be recorded, only applied (it’s for server and I don’t want to work from my server)
  • Space saving and effectiveness: I don’t need my server to output the files, because I don’t want to modify them from my server, and for a complex enough repository (with eg. larges files), output may become expensive in terms of space and time

There is this idea of “constraing repo usage where it makes sense” and “don’t waste resources.”

Of course, if you don’t want this feature in pijul, that is fine too :). I would probably write a patch and makes it lives in my pijul worktree.

pmeunier commented on March 10, 2019

Wait, don't get me wrong, asking why doesn't mean I don't want it. The reason I asked is entirely related to the risk of confusion with Git. Can you explain how you would implement this?

lthms commented on March 10, 2019

I didn’t understand it differently (sorry if the tone of my answer let you think otherwise).

To answer your question, a first and easy(-ish?) version would be to add a boolean field in a repository configuration, and to modify the behavior of several commands accordingly:

  • add, remove, revert, rollback, recordandtagwould systematically fail, and probablydiff` too
  • status would only output conflict
  • apply would always have the --no-output flag set

What do you think?

pmeunier commented on May 27, 2019

Ok, I think I know what we need here, and how to implement it.

We need another type of repository, called BareRepository. Any repository could be opened with that type, because it would contain only a subset of the tables:

  • Branches, including fields applied, rev_applied, but not the graphs.
  • External, which is the mapping from external hashes to internal ones.
  • Internal, the reverse mapping.

Then some commands, such as log and patch, would stop requiring a full Repository. That's a first step.

The next step is to allow apply to detect whether it's working in a full repository or a bare one, and to take action accordingly: if it's a bare one (i.e. if the relevant tables are 0 in the pristine, which is quite easy to detect in libpijul::backend). If the repository is bare, just add the patch hashes to the relevant branch, but don't apply anything.

This would allow Pijul to scale to almost arbitrarily large central repositories (and even better than Git). The remaining problem for scaling, which I'm taking care of, is to have large local repositories.

pmeunier commented on May 27, 2019

I'm tagging this as a good first bug. It doesn't mean that it's trivial (to begin with, it's in libpijul), but it's a good way to learn how Pijul represents things internally, and the risk of making mistakes is almost zero.

pmeunier added tag
Good first bug
on May 27, 2019