Re: [fossil-users] Discussion of Better
Quoting Richard Hipp : > On Fri, Sep 17, 2010 at 2:50 PM, > wrote: > >> Quoting Richard Hipp : >> >> I have changed answer to the 'annotate' question to "Partial" because >> Fossil's annotation seems to show the first commit in which the line >> was added, as opposed to the "last modified" criteria posed in the >> comparison's question (the question also implied that a full history >> of the line should be provided). If it is thought that first commit >> information is as useful as the last modified, I would change the >> "Partial" to something that reflects that view. Or perhaps there is an >> option to show the most recent? Or a way to track from the first >> commit down to the most recent? >> > > It should be showing the last modification. If it isn't that's a bug. > Please report the bug. Annotate is behaving as you describe and I have updated the XML diff file (at http://flashingtwelve.brickfilms.com/Temp/fossil.diff). I submitted a documentation ticket (http://www.fossil-scm.org/index.html/tktview/a182bd01a9c8dde66b1f55637b0a3e23c4099b02) against the fact that the description provided by 'fossil help annotate' does not reflect the exhibited behavior. = Modification to XML file answer: > Tracking Line-wise File History > > Does the version control system have an option to track the > history of the file line-by-line? I.e., can it show for each > line at which revision it was most recently changed, and by > whom? Yes. This capability is provided with the 'fossil annotate' command as well as through the built-in web interface. ___ 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] Discussion of Better
On Fri, Sep 17, 2010 at 2:50 PM, wrote: > Quoting Richard Hipp : > > > Thank you for taking on this task - my plate is full at the moment. > > > > Please see my edits below > > Thanks to both you and zachtodd for your feedback. > > I have changed answer to the 'annotate' question to "Partial" because > Fossil's annotation seems to show the first commit in which the line > was added, as opposed to the "last modified" criteria posed in the > comparison's question (the question also implied that a full history > of the line should be provided). If it is thought that first commit > information is as useful as the last modified, I would change the > "Partial" to something that reflects that view. Or perhaps there is an > option to show the most recent? Or a way to track from the first > commit down to the most recent? > It should be showing the last modification. If it isn't that's a bug. Please report the bug. > > I have updated the text as follows (I am only showing the questions > whose answers have been changed). > > Regards. > > = > > Atomic Commits > > > > Support for atomic commits means that if an > > operation on the repository is interrupted > > in the middle, the repository will not be > > left in an inconsistent state. Are the > > check-in operations atomic, or can > > interrupting an operation leave the > > repository in an intermediate state? > > Yes. Commits are atomic. > > > Intelligent Merging after Moves or Renames > > > > If the system keeps tracks of renames, does it support > > intelligent merging of the files in the history after > > the rename? (For example, changing a file in a renamed > > directory, and trying to merge it). > > No, renames are not intelligent (feature is on the TODO list). > > > Tracking Line-wise File History > > > > Does the version control system have an option to track the > > history of the file line-by-line? I.e., can it show for each > > line at which revision it was most recently changed, and by > > whom? > > Partial. Line-by-line history shows at which revision the line > was introduced. > > > Tracking Uncommited Changes > > > > Does the software have an ability to track the changes in the > > working copy that were not yet committed to the repository? > > Yes. Using 'fossil diff' or 'fossil gdiff'. Tracking status of > all files is also available. > > > ___ > 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] Discussion of Better
Quoting Richard Hipp : > Thank you for taking on this task - my plate is full at the moment. > > Please see my edits below Thanks to both you and zachtodd for your feedback. I have changed answer to the 'annotate' question to "Partial" because Fossil's annotation seems to show the first commit in which the line was added, as opposed to the "last modified" criteria posed in the comparison's question (the question also implied that a full history of the line should be provided). If it is thought that first commit information is as useful as the last modified, I would change the "Partial" to something that reflects that view. Or perhaps there is an option to show the most recent? Or a way to track from the first commit down to the most recent? I have updated the text as follows (I am only showing the questions whose answers have been changed). Regards. = > Atomic Commits > > Support for atomic commits means that if an > operation on the repository is interrupted > in the middle, the repository will not be > left in an inconsistent state. Are the > check-in operations atomic, or can > interrupting an operation leave the > repository in an intermediate state? Yes. Commits are atomic. > Intelligent Merging after Moves or Renames > > If the system keeps tracks of renames, does it support > intelligent merging of the files in the history after > the rename? (For example, changing a file in a renamed > directory, and trying to merge it). No, renames are not intelligent (feature is on the TODO list). > Tracking Line-wise File History > > Does the version control system have an option to track the > history of the file line-by-line? I.e., can it show for each > line at which revision it was most recently changed, and by > whom? Partial. Line-by-line history shows at which revision the line was introduced. > Tracking Uncommited Changes > > Does the software have an ability to track the changes in the > working copy that were not yet committed to the repository? Yes. Using 'fossil diff' or 'fossil gdiff'. Tracking status of all files is also available. ___ 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] Discussion of Better
On Fri, Sep 17, 2010 at 10:01 AM, wrote: > In the following message, Schlomi Fish requested that a representative > of Fossil assist in maintaining a Fossil entry for his Better SCM > website. > > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02478.html > > While I am relatively inexperienced with Fossil and probably not > qualified for fulfilling those duties, I think it'd be beneficial for > Fossil to be represented. If nobody else wishes to undertake this > task, I'd certainly be willing to do so; barring any objections. I > will defer to anybody who'd rather do it themselves, or otherwise > objects to me coordinating this activity.. > > I have attempted to address the request for information on Fossil's > capability; and edited a copy of the XML file. The diff for creating > my edited XML is available at > http://www.flashingtwelve.brickfilms.com/Temp/fossil.diff > > I have answered the questions to the best of my knowledge, but admit > that my knowledge of Fossil yet complete. I have included a plain text > version of my responses at the end of this post. > Thank you for taking on this task - my plate is full at the moment. Please see my edits below > > Criticism of the responses are welcome, whether they be wrong or just > poorly worded. > > > > Repository Operations > > - > > > Atomic Commits > > > > Support for atomic commits means that if an > > operation on the repository is interrupted > > in the middle, the repository will not be > > left in an inconsistent state. Are the > > check-in operations atomic, or can > > interrupting an operation leave the > > repository in an intermediate state? > > Commits are not atomic. > Commits are *very* atomic in Fossil - far more so than they are in git, hg, or any other VCS that I am aware of (other than perhaps monotone). Fossil commits leave the repository unmolested even if you lose power or take a system crash in the middle of a commit. Further information: http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki > > > Files and Directories Moves or Renames > > > > Does the system support moving a file or directory to > > a different location while still retaining the history > > of the file? Note: also see the next section > > about intelligent merging of renamed paths. > > Moves and renames are supported. History is retained. > > > Intelligent Merging after Moves or Renames > > > > If the system keeps tracks of renames, does it support > > intelligent merging of the files in the history after > > the rename? (For example, changing a file in a renamed > > directory, and trying to merge it). > > No, renames are not intelligent. > Currently true. This could be fixed in a future release > > > File and Directory Copies > > > > Does the version control system support copying > > files or directories to a different location at the > > repository level, while retaining the history? > > Copying is not directly supported. Duplicating > the file and adding it to the tracking would not copy > the original file's history. > > > Remote Repository Replication > > > > Does the system support cloning a remote repository to get > > a functionally equivalent copy in the local system? That > > should be done without any special access to the remote > > server except for normal repository access. > > Yes. Entire repository can be downloaded without special > permission (the copy will not track upstream changes). > More traditional cloning requires authorization (this > is typically provided to 'anonymous'). > > > Propagating Changes to Parent Repositories > > > > Can the system propagate changes from one repository to > > another? > > Yes. > > > Repository Permissions > > > > Is it possible to define permissions on access to different > > parts of a remote repository? Or is access open for all? > > Permissions are set for the whole repository. > > > Changesets' Support > > > > Does the repository support changesets? Changesets are a way > > to group a number of modifications that are relevant to each > > other in one atomic package, that can be cancelled or > > propagated as needed. > > Not directly. Changeset information is available in > "manifest" files but no commands are provided to > automate changeset operations. > > > Tracking Line-wise File History > > > > Does the version control system have an option to track the > > history of the file line-by-line? I.e., can it show for each > > line at which revision it was most recently changed, and by > > whom? > > No > Yes - there is the "annotate" buttons on the web interface and the "fossil annotate" command. I use this daily in SQLite development. > > > Features > > > > > Ability to Work only on One Directory of the Repository > > > > Can the version control system checkout only one directory of > > the repository? Or restrict the check-ins to only one > > directory? > > No. Checkouts are of the entire repository, howev
Re: [fossil-users] Discussion of Better
> Tracking Line-wise File History > > Does the version control system have an option to track the > history of the file line-by-line? I.e., can it show for each > line at which revision it was most recently changed, and by > whom? This is available from the web interface, under file history. Each checkin has an 'annotate' link to the right of it that displays line by line history with update time and the owner of the change. -Original Message- From: saulgo...@flashingtwelve.brickfilms.com Sent: Friday, September 17, 2010 10:01am To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] Discussion of Better In the following message, Schlomi Fish requested that a representative of Fossil assist in maintaining a Fossil entry for his Better SCM website. http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02478.html While I am relatively inexperienced with Fossil and probably not qualified for fulfilling those duties, I think it'd be beneficial for Fossil to be represented. If nobody else wishes to undertake this task, I'd certainly be willing to do so; barring any objections. I will defer to anybody who'd rather do it themselves, or otherwise objects to me coordinating this activity.. I have attempted to address the request for information on Fossil's capability; and edited a copy of the XML file. The diff for creating my edited XML is available at http://www.flashingtwelve.brickfilms.com/Temp/fossil.diff I have answered the questions to the best of my knowledge, but admit that my knowledge of Fossil yet complete. I have included a plain text version of my responses at the end of this post. Criticism of the responses are welcome, whether they be wrong or just poorly worded. > Repository Operations > - > Atomic Commits > > Support for atomic commits means that if an > operation on the repository is interrupted > in the middle, the repository will not be > left in an inconsistent state. Are the > check-in operations atomic, or can > interrupting an operation leave the > repository in an intermediate state? Commits are not atomic. > Files and Directories Moves or Renames > > Does the system support moving a file or directory to > a different location while still retaining the history > of the file? Note: also see the next section > about intelligent merging of renamed paths. Moves and renames are supported. History is retained. > Intelligent Merging after Moves or Renames > > If the system keeps tracks of renames, does it support > intelligent merging of the files in the history after > the rename? (For example, changing a file in a renamed > directory, and trying to merge it). No, renames are not intelligent. > File and Directory Copies > > Does the version control system support copying > files or directories to a different location at the > repository level, while retaining the history? Copying is not directly supported. Duplicating the file and adding it to the tracking would not copy the original file's history. > Remote Repository Replication > > Does the system support cloning a remote repository to get > a functionally equivalent copy in the local system? That > should be done without any special access to the remote > server except for normal repository access. Yes. Entire repository can be downloaded without special permission (the copy will not track upstream changes). More traditional cloning requires authorization (this is typically provided to 'anonymous'). > Propagating Changes to Parent Repositories > > Can the system propagate changes from one repository to > another? Yes. > Repository Permissions > > Is it possible to define permissions on access to different > parts of a remote repository? Or is access open for all? Permissions are set for the whole repository. > Changesets' Support > > Does the repository support changesets? Changesets are a way > to group a number of modifications that are relevant to each > other in one atomic package, that can be cancelled or > propagated as needed. Not directly. Changeset information is available in "manifest" files but no commands are provided to automate changeset operations. > Tracking Line-wise File History > > Does the version control system have an option to track the > history of the file line-by-line? I.e., can it show for each > line at which revision it was most recently changed, and by > whom? No. > Features > > Ability to Work only on One Directory of the Repository > > Can the version control system checkout only one directory of > the repository? Or restrict the check-ins to only one > directory? No. Checkouts are of the entire repository, however, commits can be limited to any subset of files (e.g., just the contents of a subdirectory). > Tracking Uncommited Changes > > Does the software have an ability to track the changes in the > working copy that were not yet committed to the repository? Yes. Usi
[fossil-users] Discussion of Better
In the following message, Schlomi Fish requested that a representative of Fossil assist in maintaining a Fossil entry for his Better SCM website. http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02478.html While I am relatively inexperienced with Fossil and probably not qualified for fulfilling those duties, I think it'd be beneficial for Fossil to be represented. If nobody else wishes to undertake this task, I'd certainly be willing to do so; barring any objections. I will defer to anybody who'd rather do it themselves, or otherwise objects to me coordinating this activity.. I have attempted to address the request for information on Fossil's capability; and edited a copy of the XML file. The diff for creating my edited XML is available at http://www.flashingtwelve.brickfilms.com/Temp/fossil.diff I have answered the questions to the best of my knowledge, but admit that my knowledge of Fossil yet complete. I have included a plain text version of my responses at the end of this post. Criticism of the responses are welcome, whether they be wrong or just poorly worded. > Repository Operations > - > Atomic Commits > > Support for atomic commits means that if an > operation on the repository is interrupted > in the middle, the repository will not be > left in an inconsistent state. Are the > check-in operations atomic, or can > interrupting an operation leave the > repository in an intermediate state? Commits are not atomic. > Files and Directories Moves or Renames > > Does the system support moving a file or directory to > a different location while still retaining the history > of the file? Note: also see the next section > about intelligent merging of renamed paths. Moves and renames are supported. History is retained. > Intelligent Merging after Moves or Renames > > If the system keeps tracks of renames, does it support > intelligent merging of the files in the history after > the rename? (For example, changing a file in a renamed > directory, and trying to merge it). No, renames are not intelligent. > File and Directory Copies > > Does the version control system support copying > files or directories to a different location at the > repository level, while retaining the history? Copying is not directly supported. Duplicating the file and adding it to the tracking would not copy the original file's history. > Remote Repository Replication > > Does the system support cloning a remote repository to get > a functionally equivalent copy in the local system? That > should be done without any special access to the remote > server except for normal repository access. Yes. Entire repository can be downloaded without special permission (the copy will not track upstream changes). More traditional cloning requires authorization (this is typically provided to 'anonymous'). > Propagating Changes to Parent Repositories > > Can the system propagate changes from one repository to > another? Yes. > Repository Permissions > > Is it possible to define permissions on access to different > parts of a remote repository? Or is access open for all? Permissions are set for the whole repository. > Changesets' Support > > Does the repository support changesets? Changesets are a way > to group a number of modifications that are relevant to each > other in one atomic package, that can be cancelled or > propagated as needed. Not directly. Changeset information is available in "manifest" files but no commands are provided to automate changeset operations. > Tracking Line-wise File History > > Does the version control system have an option to track the > history of the file line-by-line? I.e., can it show for each > line at which revision it was most recently changed, and by > whom? No. > Features > > Ability to Work only on One Directory of the Repository > > Can the version control system checkout only one directory of > the repository? Or restrict the check-ins to only one > directory? No. Checkouts are of the entire repository, however, commits can be limited to any subset of files (e.g., just the contents of a subdirectory). > Tracking Uncommited Changes > > Does the software have an ability to track the changes in the > working copy that were not yet committed to the repository? Yes. Using 'fossil diff'. > Per-File Commit Messages > > Does the system have a way to assign a per-file commit message > to the changeset, as well as a per-changeset message? No. Commit messages are per check in. > Technical Status > > Documentation > > How well is the system documented? How easy is it to > get started using it? Fossil is well documented. Manpage-type help is available for all commands using 'fossil help'. Fossil also includes a built-in web interface permitting easy visual exploration and administration. There are also tutorials, user guides, and WIKI available on the Web. > Ease of Deployme
