On Sat, Apr 28, 2012 at 7:03 AM, Leo Razoumov <slonik...@gmail.com> wrote:
> Hi All, > Fossil design clearly separates a project repository database from a > checkout database. It is explicitly stated in the Fossil > documentation: > > http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki > "Notice that the checkout database contains a pointer to the > repository database but that the repository database has no record of > the checkout databases. That means that a working checkout directory > tree can be freely renamed or copied or deleted without consequence." > > Unfortunately, this in not true anymore since trunk [e604d483ee55] > (2012-04-27 15:43:51). Now every time you "fossil open" a repository, > the checkout root gets recorded into config portion of the project > repo. All the checkouts ever created are displayed as "alt-root" > entries by "fossil info". The "alt-root" list can get long if one has > many checkouts. By the way, "fossil close" does *NOT* remove the entry > from the alt-root list (a bug??). The list only grows and never > shrinks. A convenient way of dispensing with checkouts by "rm -rf > path-to-checkout" leaves behind dangling references to non-existing > directories. > > To the best of my knowledge there has been no discussion of this > feature on the fossil-users or fossil-dev mailing lists. Therefore, I > would greatly appreciate if someone can explain to me > > (1) What is the purpose of the feature. > (2) Its intended use. > (3) Rational for violating long-standing Fossil design principle that > project repo database does not know its checkouts. > I added this to help me keep track of where my check-outs are located. I keep all of my repositories in a single directory so I know where they all are. But my check-outs are scattered about hither and yon, according to their use and function. Many times I'll be looking at my growing collection of repositories and wonder "where did I check this one out most recently". Or I'll be be working in a check-out and want to do some unrelated change on another branch and then wonder if I have other checkouts of the same repo sitting around anywhere. If you are thinking of moving or renaming a Fossil repository file, a listing of check-outs would be very useful in helping to determine what will break and need fixing. On a server, I often have multiple CGI scripts all pointing to the same repository. A similar feature, added at the same time, keeps track of all of the possible URLs for accessing a repository. On the main Fossil webserver for example, I just now did "fossil info fossil.fossil" and I see this: access-url: http://fossil-scm.hwaci.com/fossil 2012-04-28 access-url: http://fossil-scm.hwaci.com/index.html 2012-04-28 access-url: http://fossil-scm.org/fossil 2012-04-28 access-url: http://fossil-scm.org/index.cgi 2012-04-28 access-url: http://fossil-scm.org/index.html 2012-04-28 access-url: http://fossil-scm.org/xfer 2012-04-28 access-url: http://sqlite.org/debug1 2012-04-28 access-url: http://www.fossil-scm.org//index.html 2012-04-28 access-url: http://www.fossil-scm.org/fossil 2012-04-28 access-url: http://www.fossil-scm.org/index.html 2012-04-28 access-url: http://www.fossil-scm.org/xfer 2012-04-28 access-url: http://www.sqlite.org/debug1 2012-04-28 access-url: https://fossil-scm.org/index.html 2012-04-28 access-url: https://www.fossil-scm.org/fossil 2012-04-28 access-url: https://www.fossil-scm.org/index.html 2012-04-28 Those are the various URLs by which the Fossil repository has been accessed recently. Some are just multiple domain names assigned to the same IP address (www.fossil-scm.org vs fossil-scm.org vs fossil-scm.hwaci.com) but other actually reflect separate CGI scripts (index.html, index.cgi, fossil, xfer, and debug1). There are 65 other Fossil repositories on the same machine. A cross-reference like this is helpful in keeping track of where stuff is located. If I move or rename a repository, it gives me a quick way to find all of the CGI scripts that will need to be updated. Eventually, I'd like to add an enhancement whereby one can ask "Do I have any uncommitted changes for this project, possibly in other checkouts?" and "Do I have any uncommitted changes anywhere on this system?" The mapping from repositories to check-outs will help answer those questions. Note that mapping from repository to check-out is more of a log-file entry. It is not required to be consistent in order for the system to function. It is advisory only. So this change should not have broken anything. Yes, it would be nice if there was a way to cull these lists, similar to the "fossil all ignore" command. So many ideas... So little time... > > Thanks and Best Regards, > --Leo-- > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
