On Wed, 21 Aug 2013 17:10:59 +0200, Stephan Beal <sgb...@googlemail.com>
wrote:
On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson <m...@0branch.com> wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal <sgb...@googlemail.com>
wrote:
> DVCSs cannot, by their very nature, portably support sequential
numbers.
> This topic has been beaten to death by brains much larger than mine.
Joerg's original proposal (in a previous thread) was to support
_local_ sequential revision numbers as per Mercurial. That is, while
my revision 5 needn't match yours (e.g., autosync is off and we've
both committed), we can each still perform local operations using
these numbers (e.g., diff -r 3:5).
My argument at the time against that still stands, though: those numbers
could be changed by any given modification to either the filesystem or
the
db. Which means that 3:5 might, in 3 seconds, have a different meaning.
It's an unreliable mechanism which, after painstakingly implemented, will
eventually result in a mail with "a tried to diff using -r 3:5 and i got
a
diff of 2:4 instead." Fossil developers cannot possibly know what goes on
on your local system and will not in any way be able to help with such
problems if they cannot be reproduced easily. i could see it being
halfway
I understand it would be completely reliable for diff up merge etc. for
`commit' I don't see any usage
of either revnums or hashes to be specified by the user? and fossil
internally _of_course_ will always use the hashes.
reliable for diffs, but not commits, because any change to the filesystem
or repo can change the list of files used by the commit command.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
