Pijul

Patch based version control

Development
#1

Continuing the discussion from Random Talks and Thoughts:

I have never felt comfortable with Git. I have used Bazaar, and I recently reread an article explaining how the history is shown differently in Git, Mercurial, and Bazaar. That article claims

I’d differentiate Git from other DVCS systems by saying it’s patch oriented. The goal of Git is to arrive at some patch that describes the next state in a project- tracking history is viewed as not as important as tracking the patch or the content.

I guess that’s why I’m still not sure what to make of Pijul. It sounds great to be able to apply patches in different orders, but the main point of “version control” is to be able to get at the different versions easily, able to refer to a version in terms of a release, able to list what is in a version. This seems easier with a snapshot. Maybe that’s just my feeble mind not able to hold all the possibilities, but I’m used to seeing files and comparing one to another to see the changes.
It might be that Pijul does this, and even in an easy way, but so far, as a new user, I can’t tell.
What made sense to me was later in that article,

For lack of a better term, Bazaar is branch oriented. Both git init and hg init create new repositories. However, bzr init creates a new branch. Both git clone and hg clone create copies of repositories. The equivalent command in Bazaar, bzr branch forks a new branch. Both git log and hg log examine the history of the repository. The bzr log command shows branch history.
It’s a very subtle change in point of view. Bazaar elevates branches to the primary metaphor, relegating the concept of repository to more of a background player role.

Perhaps this makes sense because I’m used to working with files, and having another branch is another copy of the files. With that reflected in the log, there’s nothing to figure out.

The question is: Is Pijul far enough away from what Git does to fix all its problems or is it just addressing one area of concern?

#2

To best answer that question its important to understand where exactly you are coming from. Based on the quote article you refer to I infer that you are mainly thinking in terms of the Git/Mercurial/Bazaar when reasoning about version control in general. Is that the case and if so, do you mind me retreading some ground you may find very familiar to ensure we are on the same page?

Edit: Also, would it be fair to say that your main use of version control is to refer back to the changes you have made rather than to collaborate with a lot of other people? That’s where I’m coming from as a former user of Bazaar.

#3

I think it shouldn’t matter what a person’s background is. Version control should live up to its name and track versions, whether that is software releases or departmental progress.

My main use is open source software, like WordPress, which uses a mix of SVN and Git. I prefer Bazaar for my own projects, and it makes sense as an Ubuntu user. Last year, I was trying to review pull requests for a collaboration(the WordPress Twenty Twenty theme) on GitHub. I had a very difficult time trying to figure out what was what and how to test them. There was always a need to refresh from master before they could be dealt with and that seemed to pollute the “patch”, making it look like the changes in master were actually submitted in the PR. This might just be how GitHub conveys the information, and not Git itself, but if you didn’t make the change yourself, it’s so hard to see what’s going on. That is my main concern with any VCS.

One of the small projects I had was to enhance someone else’s code that has been abandoned. I tried to make a GitHub repo by giving it the SVN URL, and that only partially worked. It resulted in a repo of version 1.5 instead of the 4.3 that I gave it. But I didn’t see how I could then add in to Git the changes I had made some years before, as a new version, with the old date. (I was trying to share my changes so a client could see the whole history as it really happened, and I needed new changes on top of that.)

1 Like
#4

That came out wrong, sorry. I only meant inquire specifically about your familiarity with version control software and the rest of your reply gives me a reasonably good idea.

First off I should clarify both my understanding of a few terms as they relate to VCS and in particular DVCS.

  • version: the contents of a file or folder structure at any given moment
  • snapshot: a record that enables to completely reproduce a specific version
  • patch: a full description of the differences between any two versions
  • VCS: a program that can store and reproduce specific versions
  • DVCS: a VCS that allows multiple people to independently store versions

The ability to record and restore versions is the very core functionality of a VCS. Every VCS has some notion of snapshots regardless of how it processes versions internally.

Most of the time you should not have to worry about the precise ways in which a VCS reproduces a version, especially if you are the only one making changes. What you care about is recording changes, reviewing other versions (snapshots) and comparing versions (patches). The rest is outright counter intuitive and you should not feel bad being confused.

The difficult bit is dealing with independent changes in the same exact place in a file. It is so difficult that for the longest time the solution was to prevent the recording of any independent changes. For individuals this didn’t cause any problems to speak of, small teams working together closely could coordinate to work around the problem. Large groups of people working on the same project with little to no contact for long periods were not much worse off just making copies by hand because as you noted, snapshots are easier.

The Git/Mercurial/Bazaar wave of DVCS is essentially just automating the process of periodically taking snapshot after snapshot from each developer, comparing each of those snapshots to what you have one by one and combining them when and if need to. Depending on what you are working on you may incorporate recent changes before much folders ones, which is why ordering changes by time doesn’t really work with DVCS.

Large teams have to compare different versions all the time and apply changes from one snapshot to another, which is the extent of the “patch oriented” nature of those systems. The main difference between Bazaar and Git is that it doesn’t expose any of the complexity when you are working on your own and even makes it relatively easy to work on multiple different things in parallel on your own, although you still have to eventually apply each branch one at a time when you want to make it all work together.

The problem that Pijul tries to address is dealing with each separate snapshot as a separate version. Being able to combine patches in any order means you are no longer applying them one at a time. Furthermore, it means that it does not matter how anyone else did it as long as you get the same result. Does it help when working on your own?

That depends. When your changes can go in any order you can work on different areas in any order without having to figure out the right branch for each area before you have even started.

1 Like
#5

Pijul supports patching of patches, no? This seems to represents one more path along which feature separation/branching may occur, and one I haven’t seen discussed in this thread yet.

#6

Welp, so much for that idea. Why? Cuz:

#7

I’m not sure what question you are trying to answer, but it doesn’t seem to be the one I’m asking, which is:

#8

If that was the only thing you had written I would not have attempted to answer as the question by itself is simply too vague. However you brought up a number of issues pertaining to Git’s problems. If everything you added before the question was not there to narrow it down then I can’t really help. Sorry.