https://futureofcoding.org/ logo
Join Slack
Powered by
<https://twitter.com/heartpunkk/status/14577474803...
# share-your-work
h
https://twitter.com/heartpunkk/status/1457747480301510659 no code shared publicly anywhere yet but i could throw a snapshot up somewhere as soon as folks are interested.
a
What do the queries look like for "what version of the code does what"? Just text matching? You don't sound like you're trying to solve the halting problem but that's where my brain is stuck.
h
there's a ton of options for how you could do that; this doesn't solve that problem directly. referencing a particular snapshot would be the primary means of collaboration. there'd just so happen to be a sophisticated query mechanism available if you wanted to integrate it with other metadata sources.
tl;dr: you need to explicitly annotate snapshots with metadata about what they do, or have tooling for automating that by way of testing/analysis/review etc.
i'd heavily bias toward automated annotation myself, but i just don't consider that a primary problem here. i more mean that you can run your tests at a known snapshot and be guaranteed that's exactly the code that was tested, and associate test runs with snapshots, or whatever other analysis you do as part of your workflow
i kinda worded that part of the tweet confusingly, sorry!
s
very interesting. will this auto-sync two working copies on different machines for the same user?
h
could do, haven't thought about defaults for such things, but defs configurable or programmable for such
no sync built yet, but that can come quite soon, today's just not a dev day for me really
s
nice, its something i'd want in a new vc system. often i just have to push/pull from a different machine while syncing just my changes. sounds like we'll be able to attach metadata to snapshots which is great.
h
i guess that could be as simple as having a working copy configured for autocheckout of a particular head
tbc this isn't git/hg replacement
it's augmentation for that
need to explain that much more clearly in the future; this distinction is clearer to those inside google or who have read and really grokked the piper/citc paper
snapshotting mechanisms are far more primarily for reproducibility, enabling debug workflows, and augmenting collaboration around heavier version control systems that being said, there is absolutely no reason a layer couldn't be built on top of a system designed for snapshotting to allow it to act more like a traditional VCS
i'd prolly defer to the folks at pijul for doing VCS properly in the current sense of VCS, rather than the more automatic, snapshot oriented sense
s
oh i see. so will this require a VCS or will just work on any filesystem?
h
it won't require a vcs, and it would work on any filesystem where watchman works
which is all the major platforms rn
it's unexplored territory as to whether it makes sense to merge the functionality and affordances of snapshot based and more traditional VCS systems
i'd like to explore that with time, but that would also start to get into including undo history persistence from the editor level as an opt in for another layer of version history
otoh, i also dk how long i'll keep playing with this particular project, but it will be open source, so, others will be able to do something with it if they choose
s
so will this sync p2p or require a central file server? (cict works with piper)
h
could do either; fundamentally it must support both for my design goals
it should be reasonably possible to make either model work if you want
without terrible usability issues
like, that is a fundamental design goal for me
prolly s3, ssh, and webrtc based sync; one purely client server, one that can be used either way, and another that's more fundamentally p2p but does unfort require a public IP for nat traversal
👍🏽 1
(at least those to start; other mechanisms could exist nominally later, but those three scratch my itches the most)
s
what i'm really looking for is a replacement for syncthing with better history support. not sure if this will fit but will certainly be worth trying out. i wonder if there is a practical limit to the number of snapshots. the main issue for me with hg/git is to remember to pull and then to check-in/push. i dont actually care about commit labels, i just want files to sync across some machines with some history.
h
number of snapshots isn't a really meaningful issue IME, at least for code, and there's easy mitigations that can be added that i've already tested (you WILL have problems if you use this kind of stuff in a media scratch directory however) this could be used like syncthing plausibly, though that is not its most primary goal.
and the synchronization concerns that syncthing may address are really not a goal for me rn, so you may end up with lost writes because of last write wins sort of stuff
but that'd prolly only matter if you did fairly simultaneous access across multiple systems, which breaks everything in this space one way or another
err conflicting writes to be specific
s
i see ok. syncthing supposedly identifies conflicting writes. though i've never seen one in my years of using it.
h
so yeah, i'm not presently planning to worry about that kind of correctness concern, because if divergent copies exist, that's just fundamentally fine to me, and requires manual intervention
this would be entirely resolved if i were ready to commit to a concept like symbolic refs yet, but i'm just not at that stage of the architecture rn so
i'm worrying about data integrity and io efficiency and query stuff more rn
yea, ok, i can imagine a mode designed for this fitting in
at the stage at which trees and symbolic refs or their equivalent are represented, this is definitely doable
Open in Slack
PreviousNext
Powered by