Re: [fossil-users] An idea about mutable history*

[Stephan Beal]

On Sat, Oct 21, 2017 at 10:51 AM, Stanislav Paskalev 
wrote:

> I would imagine an implementation where by default the presentation
> DAG is the same as the raw one and having additional commands (that
> appear in the raw one as commits) to alter the presentation view.
>
> Do you think that this approach is proper and feasible ?
>

IMO it sounds both interesting and feasible (but not a small amount of
work). It's essentially a timeline view using supplemental (human-edited)
inheritance/grouping metadata. Because the timeline is the single most
complex piece of UI-centric code, though, i would recommend using a
different URI for such a feature, /timeline/alt or /alternate-reality.

It would obviously need new commands to manipulate/maintain the "adopted"
family groupings of artifacts.

One important question which would need to be answered early on is how to
store this metadata. In a new Artifact type (so that it's permanent and
immutable) or in a plain DB table (which isn't "as permanent" as an
Artifact, but it may not need to be). If it's in a new Artifact type, then
it would obviously (because of its pseudo-mutable nature) require a way to
update it for purposes of the alternate timeline (e.g. "newest update
wins").

Anyway...

There are lots of questions to pose and answer, but i think the idea has
merit.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] An idea about mutable history*

[Stanislav Paskalev]

Hi fossil users, devs,

(I don't remember this idea being discussed, sorry if it has already
been proposed.)

The more I have to use git at work, the more I come to appreciate
fossil. Yet, companies often have established processes around git'sb
quirks and peculiar behavior, making the case for switching to fossil
a tough one.

Fossil already supports a sort of mutability - by adding branches,
appending edits and so on. What if this mechanism is fully extended
towards a presentation DAG ? This means keeping the current,
history-preserving behavior while allowing for two views into the
repository - the raw, as-is and the altered, as-should-be.

This allows for example to have a history that is always buildable and
testable, therefore making bisects easier. It also allows for a
high-level view, where multiple raw commits can be grouped into
logical ones for better readability/

I would imagine an implementation where by default the presentation
DAG is the same as the raw one and having additional commands (that
appear in the raw one as commits) to alter the presentation view.

Do you think that this approach is proper and feasible ?

Regards,
Stanislav Paskalev
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users