And blindness indeed. The download option may be found in check-in pages. Therefore the latest trunk check-in download link is found at: http://www.fossil-scm.org/index.html/info/55a28e7f5a
Thanks again. ^K on Dec 20, 2012, Richard Hipp <d...@sqlite.org> wrote: > > > >On Thu, Dec 20, 2012 at 8:40 PM, K <k...@lightpowered.org> wrote: > > > >Thank you for refining the presentation of moved-not-deleted files. > > > >Is this code now integrated into the primary trunk, >Yes. In http://www.fossil-scm.org/fossil/timeline?c=2012-12-18&nd at >2012-12-18 02:38 you can see where the changes were merged into trunk. > > > > > or at least is that the intention? My question when I went to do commits for > these >moves just became, "how do I ensure I continue to use the improved code". > > > > > >Thanks again, > >^K > > > >on Dec 17, 2012, Richard Hipp <d...@sqlite.org> wrote: > >> > >> > >> > >>On Mon, Dec 17, 2012 at 9:12 PM, K <k...@lightpowered.org> wrote: > >> > >> > >> > >> > >> > >>However, I'm still curious why files must split upon move? > >> > >>It isn't a requirement. The page is simply showing all artifacts that >>represent >a > >>file with a given name. That is one way to slice the data. You are wanting >>to >track > >>a file throughout its revision history and through name changes. That is a >>different > >>way to slice the data. Both views are useful. > >> > >> > >> > >>The "file-by-name" view is currently used because it is the simplest to >>implement, > >>in several ways. (1) The file you want to look at has a unique name, so you >>just > >>include that name as a query parameter on the URL. (2) You can look up all >>changes > >>by querying the database once by that name. > >> > >> > >> > >>File-history-through-name-changes is more complicated. For example, how do >>you >specify > >>what file you want to look at in the URL. You cannot just say "file1.txt" >>any more, > >>because two or more different files might have passed through that name >>during their > >>history. I suppose you would have to specify the filename and a particular >>check-in > >>at which the file had that particular name. So you have two query parameters >>instead > >>of one. Then down in the implementation, it is now necessary to query the >>database > >>again for each name-change. This all adds up to more complication. Since >>nobody > >>has (yet) requested file-history-through-name-changes, it was easier just to >>leave > >>it out. > >> > >> > >> > >> > >> > >> > >> > >>Issue #1 still exists btw. > >> > >>Fixed in the latest check-in. > >>-- > >>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 > >> > >_______________________________________________ > >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 > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
