Hi all, sorry for jumping into this discussion, but I'd like to give some remarks regarding Monotone, cause I am working on a Monotone backend.
On Thursday 04 May 2006 11:32, Christian Boos wrote: > 1. Follow the global sequence order, skipping revisions irrelevant > for the path. That's what we do currently for SVN. > This *could* also work for Mercurial, where each repository > maintains its own global sequence numbers. > I'm not sure about other VCS. Assuming global sequence numbers for revisions is problematic. Monotone doesn't have anything like this. The revisions simply form a dag. One can of course sort all revisions according to their timestamps, but besides from the TimeLine view, this might not be meaningfull at all. Following 'previous' and 'next' links will then jump between different branches and thus possibly between different projects. > 2. Stay on the branch to which the revision belongs to. > This is not relevant for SVN, as the branch information is tied > to the path and the memory of where that path came from. > But Mercurial and I believe most other systems (even CVS, at the > file level) have the concept of a revision being part of a given > branch. What about branch endpoints, i.e. merges? In Monotone, a revision can easily belong to more than one branch. And, even worse, Monotone has 'micro-branches', that is, a revision can have more than one child or more than one parent, all belonging to the same branch. Now, regarding the proposed node_changes table, (at least for Monotone) it would be necessary to allow two (change_type, base_path, base_rev) tuples, because a node in a certain revision might be the result of a merge of two parents. This is of course a general problem of the current Node.get_history() resp. Repository.get_path_history() interface, that assumes a linear history for a node up to it's creation. - Thomas -- Thomas Moschny <[EMAIL PROTECTED]> _______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
