unisonweb/unison
1
0
Fork 0
mirror of https://github.com/unisonweb/unison.git synced 2024-09-17 13:27:30 +03:00
Code Issues Projects Releases Wiki Activity

wip

Browse Source
This commit is contained in:
Arya Irani 2019-04-23 10:58:49 -04:00
parent 962d0aeec9
commit fbfc487dc5
2 changed files with 99 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
docs/branchless-scratch.md Normal file
View File

@ -0,0 +1,57 @@
### Remembering local/remote codetree associations?
```haskell
-- Designates remote paths to sync local paths against
newtype RemoteMap = RemoteMap { toMap :: Map (Path, RemoteName) RemotePath }
```
If I have some branch (tree node) that I want to sync with github on an ongoing basis. e.g. `/projects/foo` to `github:aryairani/foo` — that becomes a place I can publish to or pull from, how should I associate the two? If I
If I associate it by path, then what should happen when I move or copy the node in the tree? What do I have to update to make that happen?
What happens if I associate it by `Causal` hash?
```
# parenthesized hashes represent the branch hash
/projects (mZm)> remote.set github:user/foo foo
Set remote github:user/foo for /projects/foo (0e9).
```
/projects/foo (0e9) linked to github:user/foo
```
/projects (mZm)> cp foo foo-fork
/projects (wkP)> cd foo-fork
/projects/foo-fork (0e9)> add myFunc
Added myFunc.
/projects/foo-fork (p3z)>
Should now have:
/projects/foo (0e9) linked to github:user/foo
/projects/foo-fork (p3z) linked to github:user/foo
```
```
# types
.unison/types/<hash>/compiled.ub
.unison/types/<hash>/dependents/<hash>
.unison/types/_builtin/<base58>/dependents/<hash>
# terms
.unison/terms/_builtin/<base58>/dependents/<hash>
.unison/terms/<hash>/compiled.ub
.unison/terms/<hash>/type.ub
.unison/terms/<hash>/dependents/<hash>
# branches
.unison/branches/<hash>.ubf
.unison/branches/head/<hash> -- if several, merge entries to produce new head.
# edits
.unison/edits/<guid>/<hash>
.unison/edits/<guid>/name/<base58> -- (base58encode (utf8encode "name of the edit"))
.unison/edits/<guid>/head/<hash> -- if several, merge entries
# remotes
.unison/remotes/
```

42
docs/branchless.md
View File

@ -104,6 +104,7 @@ Given:
/A/B/c#xxx
/D/E/f#yyy (depends on #xxx, #zzz)
/D/G/h#zzz
/libs/G/bar#zzz
```
If `/D/E` is published, what names should be assigned to `#xxx`, `#zzz`?
@ -136,6 +137,47 @@ The nearest aux-name would only be used to render code only if there were no pri
### Idea 5: Something with symlinks
```haskell
data Branch' m = Branch' (Causal m Namespace)
data Causal m e
= One { currentHash :: Hash, head :: e }
| Cons { currentHash :: Hash, head :: e, tail :: m (Causal e) }
-- The merge operation `<>` flattens and normalizes for order
| Merge { currentHash :: Hash, head :: e, tails :: Map Hash (m (Causal e)) }
-- just one level of name, like Foo or Bar, but not Foo.Bar
newtype NameSegment = NameSegment { toText :: Text } -- no dots, no slashes
newtype Path = Path { toList :: [NameSegment] }
data Namespace m = Namespace
{ terms :: Relation NameSegment Referent
, types :: Relation NameSegment Reference
, children :: Relation NameSegment (Link m)
}
data Link m = LocalLink (Branch' m) | RemoteLink RemotePath
data RemotePath = Github { username :: Text, repo :: Text, commit :: Text } -- | ... future
```
This lets us avoid redistributing libs unnecessarily — let the requesting user get it from wherever we got it from. But it doesn't specifically address this external naming question.
We might be publishing `/app/foo` which references definitions we got from `repo1`. Somewhere in our tree (possibly under `/app/foo` and possibly not?) we have a link to `repo1`.
Somewhere under `/app/foo` we reference some defn from `repo1`.
Transitive publication algorithm:
* find all the things that you're referencing
* the things you're publishing that aren't under the pbulication point need to be resolved
* they're local, and need to be given names under the publication point
* user is notified, or we do something automatic
* they're remote, and we need to include, in the publication, a link to the remote repo.
* user is notified, or we do something automatic
* "Something automatic" will be:
* mirror the dependency names from our namespace into `./_Libs`; if it would produce naming conflicts to use `./_Libs`, then `_Libs1`, etc.
* Or, just dump them into `./_Libs` and if doing so produces naming conflicts, force the user to resolve them before publishing.
## Syncing with remote codetrees
```haskell