Follow

Seeking opinions on version control 

This is a very open ended question: if you were to design a version control system for yourself, what would you like it to have?

For me, non-broken cherry picking (like Git's), immutable revisions but safe mutable history (a la Mercurial's evolve extension) and the ability to mark tags as "withdrawn" with a message instead of either ignoring or removing them

Seeking opinions on version control 

@urso This is kinda in the domain of tooling, but something like git-bisect would be important.
Also, a clear and concise set of concepts to learn, and a clear UI for usage would be an improvement over the most common version control systems.

Seeking opinions on version control 

@shello bisecting should be central to the tool, IMO

darcs has `darcs test`, which works similarly but gives more choices for testing. It also has an UI that I rather like

why did I ask that: I was reading some of the Mercurial internals documents and, since I don't have anything better to do, I started sketching how would a VCS be implemented

nothing serious, but it's been fun up until now

Seeking opinions on version control 

@urso
@shello

I'd want an option to require signatures using some sort of PKI. I don't care if it's web of trust or via a CA, I want to be able to confirm that a commit came from a particular user. This can even be just based on a signed hash of the diff output; something that can quickly verify authorship.

Seeking opinions on version control 

@zenrider @urso That reminds me something important that crossed me a few months ago: not having the actual name or the email address tied to commits, but instead using a proxy value that is set at the repo level (optionally) associated with an author name and email.
People change their name and email address all the time, and they also make mistakes setting up those values. At least how git structures it, changing of these values is generally not viable.

Seeking opinions on version control 

@shello
@urso
I run into this regularly at work; I contribute to many repos as part of my job, and each one has a different specific email associated with it.

I'd also love to see more filetype-aware diffing, so that merges that involve, say, multiple properties of an XML element being added don't conflict, but changes to some looping logic will raise a merge conflict.

Seeking opinions on version control 

@zenrider @shello Mercurial has this concept of changeset evolution. I already added a note about this particular issue, but in my experience it's something people figure out quickly

as for different e-mails for different jobs, I imagine having a repo-specific name+email combo helps? I'm not sure but I think git already supports that, and I know mercurial supports it too

Seeking opinions on version control 

@zenrider @shello so far my general ideas are based off of problems I had with git

- immutable and mutable branches
- mutable branches allow for "safe" history mutation (i.e. records are never destroyed, they're just replaced by newer ones) with a good trail to know where a certain record came from
- the ability to add notes to records, and use that as a simple workflow for code review
- branch names have a canonical ID to prevent clashes

Seeking opinions on version control 

@zenrider @shello

- tags can be withdrawn instead of removed. The difference is semantic, I suppose, but say you want to tell users a certain version has a bug and should not be downloaded. By removing the tag, it ceases to exist and you lose that context. By withdrawing it, you can add a note about it

Seeking opinions on version control 

@zenrider @shello

> I'd also love to see more filetype-aware diffing

That's semantic diffing... my gut feeling tells me that this is to try and bite more than I can chew

Seeking opinions on version control 

@zenrider @shello I suppose, as long as that's optional at the repo level. I believe mandating signatures, while good, adds some burden when first setting up (good for someone familiar with it, but it's not beginner friendly) and some cognitive load

I'll think about it. Perhaps it can be enforced at a branch level?

Seeking opinions on version control 

@urso
@shello
I wouldn't want to enforce signatures, but it'd be a nice-to-have as opposed to how Git handles (sort of) PGP signing.

Seeking opinions on version control 

@zenrider @shello regarding the trust thing, I wonder if using RSA for the trust thing is enough 🤔

Seeking opinions on version control 

@urso

@shello

If your project runs its own CA and issues certificates, any signing key would do (ECDSA, for example.) My thought would be to sign the hash of the diff and the commit message, and include that at the end of the commit message (or as another field if there was room in the schema).

Seeking opinions on version control 

@zenrider @shello the design of the schema as it is right now (super unstable, I'm talking hypothesis level here) the signature would have to be on the header, right before the commit hash. It kinda copies Mercurial's revlog model, so a strong signature would have to take into account the other hashes involved as well

I'll have to think a bit more about this.

Sign in to participate in the conversation
Bear.community

Bear.community is a 18+ only Mastodon server for bears, chubbies and chasers.