Re: [fossil-users] scrub --private doesn't remove new private branch
On Wed, Dec 19, 2012 at 1:05 PM, Maxim Khitrov m...@mxcrypt.com wrote: Hello, I was trying to remove a private branch from the repository, but the scrub --private command didn't work as expected. The following commands are executed on Windows 7 using fossil 1.24 (renamed to fs): D:\fs clone https://www.fossil-scm.org/ fossil-scm.fossil D:\mkdir fossil-scm D:\cd fossil-scm D:\fs open ..\fossil-scm.fossil D:\fs branch new --private private trunk D:\fs scrub --private Scrubbing the repository will permanently delete information. Changes cannot be undone. Continue (y/N)? y fs: SQLITE_ERROR: no such table: main.delta fs: no such table: main.delta CREATE INDEX IF NOT EXISTS delta_i1 ON delta(srcid); CREATE TABLE IF NOT EXISTS shun( uuid UNIQUE, mtime INTEGER, scom TEXT ); CREATE TABLE IF NOT EXISTS private(rid INTEGER PRIMARY KEY); CREATE TABLE IF NOT EXISTS concealed( hash TEXT PRIMARY KEY, mtime INTEGER, content TEXT ); If you have recently updated your fossil executable, you might need to run fossil all rebuild to bring the repository schemas up to date. D:\fs ui The private branch that I created is still there in the timeline. I'm also not sure what causes the errors about missing tables. Running rebuild doesn't seem to help. Am I doing something wrong? Anyone? Is this the expected behavior or a bug? - Max ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] scrub --private doesn't remove new private branch
On Thu, Dec 20, 2012 at 8:30 AM, Maxim Khitrov m...@mxcrypt.com wrote: Anyone? Is this the expected behavior or a bug? It sounds like a bug, but I've been busy with other things and have not had an opportunity to investigate. -- 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
Re: [fossil-users] Writing Linux kernel-style commit messages in Fossil
On Wed, Dec 19, 2012 at 4:14 AM, Arnel Legaspi jalespr...@gmail.com wrote: Hello, Is there a way to have Linux kernel-style commit logs display the way they should be in the Fossil web UI? By Linux kernel-style commit logs I mean the way Tim Pope described it below: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html At the moment, multiple-line commit messages show up shortened in Fossil (see http://www.fossil-scm.org/index.html/info/64868f2b98 for an example). What we would like to see is to have only the summary line be displayed on the Timeline page, and to have both the summary line and the rest of the commit message after the blank line show up on the specific commit page instead (when you click on the hash in the Timeline page). +1 from me on this feature request. I'd definitely appreciate the ability to use the commit title, 2 X newline, more details style of checkin message if it formatted nicely in fossil. If there's no way to currently do so , we'd like to make a feature request for it. Thanks! --Arnel ___ 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
[fossil-users] spurious CRLF generated by `finfo -p' (and other terminal output)
hi, I accidentally noted that all terminal (stdout) output of `fossil' seemingly uses CRLF (\r\n) as EOL even on unix-based machines (i.e. everything in the world except those view machines running something else ;-)). at least it does so under MacOSX. I would find it more reasonable if `fossil' would adjust its EOL convention to that of the underlying OS. especially `fossil finfo -p somefile.txt acopy.txt' is rather annoying since (assuming *CURRENT* is at the respective `leave') the checked out version of `somefile.txt' is then _not_ identical to `acopy.txt' (since the latter has the CRLF EOLs while `somefile.txt' has not). is this considered a bug?? if not so, could this behavior be changed nevertheless? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] PLOS (II)
hoping that this does not generate so much turbelence as the mv/rm issue did: I've stumbled over this behavior: -- there is a user account on a remote repo created for me (with commit access) -- I do the clone a la `fossil clone http://myname@URL myrepo.fsl and I'm asked correctly for the password of user `myname'. -- I open my repo, edit stuff and commit/push -- commit/push turns out to use my $USER (local user name) and that's how it appears on the remote sites timeline well, I was heavily surprised which proofs that PLOS was violated. (least surprising always being that things don't work at all...). I would find it far more intuitive if _after_ a `clone' of the above sort (password query for `myname' and all) the corresponding local user would be created automagically and also be set to the default user so that I'm directly interacting correctly with the remote server. presently (and that's the parallel to the mv/rm discussion) I have to perform manual interaction (create user with password (take care to use the same as on the server here?) and make him the default user) which again 99.9% of the time should be what the user wants anyway (and might be really surprised to not have happened autmatically). right or wrong? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] spurious CRLF generated by `finfo -p' (and other terminal output)
On Thu, Dec 20, 2012 at 12:47 PM, j. van den hoff veedeeh...@googlemail.com wrote: hi, I accidentally noted that all terminal (stdout) output of `fossil' seemingly uses CRLF (\r\n) as EOL even on unix-based machines (i.e. everything in the world except those view machines running something else ;-)). at least it does so under MacOSX. I would find it more reasonable if `fossil' would adjust its EOL convention to that of the underlying OS. especially `fossil finfo -p somefile.txt acopy.txt' finfo does not use any EOL. It simply outputs what is in your file. It treats all files as binary. If you are seeing \r characters in the output above, that is because you checked \r characters into somefile.txt, I think. is rather annoying since (assuming *CURRENT* is at the respective `leave') the checked out version of `somefile.txt' is then _not_ identical to `acopy.txt' (since the latter has the CRLF EOLs while `somefile.txt' has not). is this considered a bug?? if not so, could this behavior be changed nevertheless? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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
Re: [fossil-users] spurious CRLF generated by `finfo -p' (and other terminal output)
On Thu, 20 Dec 2012 19:03:07 +0100, Richard Hipp d...@sqlite.org wrote: On Thu, Dec 20, 2012 at 12:47 PM, j. van den hoff veedeeh...@googlemail.com wrote: hi, I accidentally noted that all terminal (stdout) output of `fossil' seemingly uses CRLF (\r\n) as EOL even on unix-based machines (i.e. everything in the world except those view machines running something else ;-)). at least it does so under MacOSX. I would find it more reasonable if `fossil' would adjust its EOL convention to that of the underlying OS. especially `fossil finfo -p somefile.txt acopy.txt' finfo does not use any EOL. It simply outputs what is in your file. It treats all files as binary. If you are seeing \r characters in the output above, that is because you checked \r characters into somefile.txt, I think. thanks for the quick answer. you are right, there are no \r, but the reason is different (still my fault!): I use a wrapper script for driving `fossil' and _that_ script somehow injects the \r. I have to check this. really sorry for the additional noise j. is rather annoying since (assuming *CURRENT* is at the respective `leave') the checked out version of `somefile.txt' is then _not_ identical to `acopy.txt' (since the latter has the CRLF EOLs while `somefile.txt' has not). is this considered a bug?? if not so, could this behavior be changed nevertheless? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] PLOS (II)
On Thu, Dec 20, 2012 at 11:56 AM, j. van den hoff veedeeh...@googlemail.com wrote: I would find it far more intuitive if _after_ a `clone' of the above sort (password query for `myname' and all) the corresponding local user would be created automagically and also be set to the default user so that I'm Nothing to do with computers is intuitive. At best, it's familiar because it acts like something else you had to learn to use. Personally, I'd be *very* surprised if I cloned a repo and it copied *any* password information, no matter what auth* was done during the clone. That's just a huge security faux pas. Creating users without passwords is even worse. which again 99.9% of the time should be what the user wants anyway (and might be really surprised to not have happened autmatically). I disagree. It might be what the user wants to happen 99% of the time for local clones, but I'd say that the current default (current login name) does that 99% of the time as well, without opening up the possibility of unknowingly handing someone a clone that includes your password. For remote clones - things change. I almost never want the same password on the two ends (again, a security faux pas) and don't really care whether or not the username is the same. Given that it takes one command to create a user password vs. one command to set the password, automatically creating the same username with a new password is at best a meh. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] PLOS (II)
On Thu, 20 Dec 2012 19:37:35 +0100, Mike Meyer m...@mired.org wrote: On Thu, Dec 20, 2012 at 11:56 AM, j. van den hoff veedeeh...@googlemail.com wrote: I would find it far more intuitive if _after_ a `clone' of the above sort (password query for `myname' and all) the corresponding local user would be created automagically and also be set to the default user so that I'm Nothing to do with computers is intuitive. At best, it's familiar because it acts like something else you had to learn to use. I don't quite agree but let's not argue. Personally, I'd be *very* surprised if I cloned a repo and it copied *any* password information, no matter what auth* was done during the clone. That's just a huge security faux pas. Creating users without passwords is even worse. which again 99.9% of the time should be what the user wants anyway (and might be really surprised to not have happened autmatically). ???... in the considered scenario, after the initial (password protected/queried) clone I _can_ push and do anything else the respective user is allowed to do upstreams. the only thing is: all this happens using my local $USER name instead of the name chosen for the remote account. I'm only proposing it would be nice to set up the clone including a local user of the remote name as the default user (he might very well get a different password as far as I can see). what security holes do you see here? I disagree. It might be what the user wants to happen 99% of the time for local clones, but I'd say that the current default (current login name) does that 99% of the time as well, without opening up the possibility of unknowingly handing someone a clone that includes your password. if I _can_ push directly after issuing the respective password _once_ during the initial clone (even if that happens with the wrong ID, namely the local $USER ID), the password info necessary for the remote access seems to be in the repo anyway, no? For remote clones - things change. I almost never want the same password on the two ends (again, a security faux pas) and don't really care whether or not the username is the same. Given that it takes one command to create a user password vs. one command to set the password, automatically creating the same username with a new password is at best a meh. I'm just proposing to automate what you do manually in the considered situation (including chosing a different local password, why not?): create the user, make him the default, choose some (local) password. where'd be the problem? maybe there _is_ an essential problem but I don't see it. let's stop it at that thx for responding. j. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] PLOS (II)
On Thu, Dec 20, 2012 at 2:11 PM, j. v. d. hoff veedeeh...@googlemail.com wrote: On Thu, 20 Dec 2012 19:37:35 +0100, Mike Meyer m...@mired.org wrote: I'm just proposing to automate what you do manually in the considered situation (including chosing a different local password, why not?): create the user, make him the default, choose some (local) password. where'd be the problem? Well, for one, it's a violation of what POLS means (as opposed to simply I was surprised). POLS means that you can correctly extrapolate how the software will behave in some situation by observing how it behaves in other situations. Fossil always uses the current login name as the default user name when a repo is created (whether by cloning or ab initio). Since that's the only observed behavior, doing that in one particular instance can't be a violation of POLS. In fact, if fossil were to change so that some particular case the default user name were something else, that would be a violation of POLS. And as I said, just setting the user name doesn't buy anything. Either it's a clone that's not going to have a password, in which case the default user name is already what I want it to be, or it's going to need a password, in which case I have to issue one command whether the user exists or not. I don't believe that this change would buy anything, much less enough to warrant the violation of POLS that it calls for. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] PLOS (II)
*stops biting tongue* To be fair, Git and Mercurial each require you to set a username/email address in their respective configuration files. If you don't, commits appear as originating from your login name plus some best-guess attempt at an email address. *watches as various folks scramble to make Fossil less like everything else and start advocating to change this behavior* To be clear, the username I clone a repository from is my username on that site. If I want the usernames to agree locally and remotely, it is my responsibility to set them equivalently. I like the current behavior. My initial idea of what username meant was as some shared global identifier, but in Fossil the username has no meaning outside of the repository. So instead of assigning globally unique identifiers, Fossil usernames are more like adding an SSH key to a server running some other VCS. Anyone with the key and credentials can authenticate, but they can then publish content to that server attributed to whomever else they wish. If I set my name/email address to yours in a Git repository, I can likewise publish commits that appear to originate from you. On 12/20/2012 03:36 PM, Mike Meyer wrote: On Thu, Dec 20, 2012 at 2:11 PM, j. v. d. hoff veedeeh...@googlemail.com wrote: On Thu, 20 Dec 2012 19:37:35 +0100, Mike Meyer m...@mired.org wrote: I'm just proposing to automate what you do manually in the considered situation (including chosing a different local password, why not?): create the user, make him the default, choose some (local) password. where'd be the problem? Well, for one, it's a violation of what POLS means (as opposed to simply I was surprised). POLS means that you can correctly extrapolate how the software will behave in some situation by observing how it behaves in other situations. Fossil always uses the current login name as the default user name when a repo is created (whether by cloning or ab initio). Since that's the only observed behavior, doing that in one particular instance can't be a violation of POLS. In fact, if fossil were to change so that some particular case the default user name were something else, that would be a violation of POLS. And as I said, just setting the user name doesn't buy anything. Either it's a clone that's not going to have a password, in which case the default user name is already what I want it to be, or it's going to need a password, in which case I have to issue one command whether the user exists or not. I don't believe that this change would buy anything, much less enough to warrant the violation of POLS that it calls for. ___ 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
Re: [fossil-users] Clarification on file move being treated as file deletion.
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-18nd 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
Re: [fossil-users] Clarification on file move being treated as file deletion.
That is great to see. So I've looked in Download and Code, and I am still not able to figure out how I can download a snapshot of the current source of trunk. Please pardon what must be blindness on my part. ^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-18nd 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
Re: [fossil-users] Clarification on file move being treated as file deletion.
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-18nd 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
Re: [fossil-users] Clarification on file move being treated as file deletion.
It isn't blindness, I'm blind and did notice the download links previously. I'm not trying to be pedantic, I just don't like seeing my disability used when someone misses the obvious and is looking for a term to use. I'm routinely treated as if I must not notice the obvious, and it's one of the most frustrating stereotypes I encounter. Thanks. On 12/20/2012 08:31 PM, K wrote: 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-18nd 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
