On Thu, May 8, 2014 at 12:29 PM, Jan Nijtmans <jan.nijtm...@gmail.com>wrote:
> tests to assure that. Actually, fossil cannot do very much when dealing > with an empty repository. Merging??? against what branch???? > It's funny you say that because in libfossil i've had to go back and reexamine my 0 semantics, and let them be legal (empty repo) in some cases, but stand for the current checkout in others (where 0 otherwise makes no sense). Negatives are always invalid, but 0 has a few uses. In some cases, there's a small bit of extra handling for rid 0, but nothing tragic. > I did additional tests to assure that historical compatibility is not > affected. > Three scenario's: > - When people use an already exisiting repository, the initial empty > commit is already there. Nothing to worry about. > - When creating a new repository, no initial commit is there. But as > soon as the first commit goes in, everything is exactly as before. > Basic operations like add/remove/addremove/commit work fine > even without the initial commit, other operations make no sense yet. > i agree: i also don't expect any problems if this is made the default (other than potential initial long-time user confusion, which they will quickly get over when they realize they can finally write the first commit message in their native language ;). > I didn't need an axe for this work, the possibility to create an initial > empty commit is still there. But if during the timeline towards fossil > 1.29 something unexpected is discovered: It's only a one-line > code change easy to revert! > Sounds like a plan :) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "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
