... > Thus said B Harder on Thu, 02 Oct 2014 11:17:23 -0700: > > > Is that even possible? I thought the repo would have to > be created > > once (and only once), generating it's repo-id, and then > cloned for all > > subsequent copies before things can begin deviating. > > The project-id is stored in a table in a database---it can be > changed. I > suspect that this is how Chiselapp actually allows you to > sync a new > repository to their site in some configurations. Because > the act of > creating a new repository necessarily also includes an > initial commit > (older versions of Fossil), you end up with two trunks > because there > were actually 2 repositories created, not one. The ability > to create a > repository without an initial commit might be something > that Chiselapp > could take advantage of in this case. ...
Yes, I think you guys solved the mystery (side effect of the project ID change magickry). Now the question is whether that behaviour of creating two disjoint trees in one repo upon project id change is a bug. Well, I'll leave that for others to ponder; I'm satisfied for now, and I'll make a concientious effort in the the future to merge the two trunks immediately to prevent downstream weirdness as a coping strategy. Thanks- -dave _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
