2014-05-01 12:28 GMT+02:00 Stephan Beal <sgb...@googlemail.com>:
> No objections, but some comments...
>
> - libfossil has been using repos without an initial commit since last
> summer. AFAIK there are no more open assertions related to that, but every
> now and then i'll run into a case which expects an RID>0 and might (until
> the first commit) see a 0. It can always be repaired when this happens, but
> triggering it can be cumbersome to do (i.e. there might eventually be some
> (now-invalid) assertions which eventually need to be patched for this).
In fossil, all of those (now-invalid) assertions have been fixed, I
did extensive
tests to assure that. Actually, fossil cannot do very much when dealing
with an empty repository. Merging??? against what branch????
> - Whether or not it should default to having no initial empty commit is
> debatable, but i can't argue strongly either way. i tend to think it should
> do one by default, solely for historical compatibility, but OTOH it's not a
> critical functionality (just an immediately-visible change for long-time
> users).
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.
2014-05-01 21:42 GMT+02:00 Andy Goth <andrew.m.g...@gmail.com>:
> On 5/1/2014 2:11 AM, Gerald Gutierrez wrote:
>> Too big. Chiselapp has an 8MB upload size limit.
> That explains it. You created a new repository and pushed to it, but that
> new repository had that unwanted empty commit, set to the current date and
> time.
>
> Whenever I convert an existing project to Fossil, I have to do [fossil new
> -date-override] to specify the date of the initial commit, putting it before
> the oldest commit I'm going to be putting into it.
Well, I went ahead, and merged the proposed change to trunk. This
means that the initial empty commit is no longer created by surprise,
but it's only a change of the default behavior: When specifying
"--date-override", everything works as before. So I don't think
existing behavior of importing and/or using already existing
repositories will be affected in any way.
Thanks for all remarks. But .... if anything unexpected happens
which I didn't foresee, please report.
2014-05-01 22:21 GMT+02:00 B Harder <brad.har...@gmail.com>:
> I think that initial empty commits went in at my request. Iirc, so I could
> have related (but not inheriting from trunk) vendor branches. Can we
> review/discuss before axing?
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!
Happy testing.
Jan Nijtmans
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
