Page MenuHomePhabricator

Create snapshots in Phragment
Closed, ResolvedPublic

Description

Phragment provides a way for each individual file to be versioned, and each fragment can be updated on it's own. However, it would be useful to be able to create snapshots of a fragment and all it's child fragments:

  1. To create a versioned package, I'd update a fragment from ZIP and maybe create a snapshot of that fragment called "myapp-1.0". Even if child fragments are individually changed under the fragment later on, accessing the fragment at "myapp-1.0" will always give me the child fragments at the versions they were when the snapshot was taken.
  2. To track the latest stable and development versions of a package, I might automatically take snapshots of a fragment after the build has published a fragment, and I might call this snapshot "development". Creating a snapshot of the same name on the same fragment as a previous snapshot moves the snapshot pointer. Occasionally I can snapshot the fragment as "stable", effectively giving my software two update channels.

I would imagine the database structure being something like this:

  • PhragmentSnapshot
    • phid
    • primaryFragmentPHID
    • snapshotName
  • PhragmentSnapshotChild
    • snapshotPHID
    • fragmentPHID
    • fragmentVersionPHID

After creating a snapshot of a ZIP file with two child fragments inside it, those tables might look like:

PhragmentSnapshot:

idphidprimaryFragmentPHIDsnapshotName
1PHID-PHRS-iqzxpmoafts5xtxqlphcPHID-PHRF-n36ni7cyrof2ntl7sckostable

PhragmentSnapshotChild:

idsnapshotPHIDfragmentPHIDfragmentVersionPHID
1PHID-PHRS-iqzxpmoafts5xtxqlphcPHID-PHRF-n36ni7cyrof2ntl7sckoPHID-PHRV-ciqbyolvkybarfh2plzx
2PHID-PHRS-iqzxpmoafts5xtxqlphcPHID-PHRF-7bsdbkhni5r6rpu7gqimPHID-PHRV-nuaphi4zxbmchsj5gzuq
3PHID-PHRS-iqzxpmoafts5xtxqlphcPHID-PHRF-tjpttwgdgz7ujl5z2qcnPHID-PHRV-khmnij52cjohw5u3mlsx

Here, PHID-PHRF-n36ni7cyrof2ntl7scko is the ZIP file. We record this as primaryFragmentPHID so we know exactly what fragment the snapshot was created against (and thus from here the snapshot can be deleted or w/e).

We obviously record the exact versions of all the child fragments as well. However, because we record the PHIDs we can do things like showing "In Snapshots: stable, development" in the history view and in the browse view (when the latest version is in a snapshot).

This means that Conduit methods will also allow you to provide a snapshot name when asking for a version or the differences between hashes and a version of a fragment.

Revisions and Commits

Related Objects

Event Timeline

hach-que claimed this task.
hach-que raised the priority of this task from to Needs Triage.
hach-que updated the task description. (Show Details)
hach-que added a project: Phabricator.

This looks good to me. The only case I can think of where it might break down is where you have:

myapp/releases/

...and you want to get myapp/releases/ at stable, i.e. the most recent stable release. However, if the directory under releases/ looks like this:

myapp/releases/version-1.0/
myapp/releases/version-2.0/
myapp/releases/version-3.0/

...you really want to tag stable one level down, but you want clients to request at the base. I'm not sure this will be an issue in practice, and if it is we could pursue any number of reasonable approaches (e.g., add a rootFragmentPHID column, which would optionally store a subdirectory of the snapshotted phragment, to let you tag releases/ but tell Phragment that it should only care about version-3.0/* for this particular snapshot).

I don't think that will be an issue in practise as I can't see where you would have "version-1.0" folders. It's much more likely that you'll have a "version-1.0" snapshot on the "releases" folder, and you will promote the "stable" snapshot up to different versions.

The only case I can think of is where you actually have multiple version branches in source control, and you're building like version 2.5, 2.6 and 2.7 streams of a project. In that case the software versions are probably not entirely compatible anyway (otherwise everyone would just have to upgrade to the next major version without issue) and thus you probably want people to be explicit in the version number they want.