Re: [fossil-users] basic questions about fossil
Quoting Russ Paielli russ.paie...@gmail.com: ... At first I was interested in Git and BitKeeper. Then I discovered Bazaar, and I was almost ready to start using it, but I decided to take one more look at the options. When I saw fossil, I figured, with a name like that, it's a real long shot, but I'll take a look anyway. ... You might be interested in visiting http://better-scm.berlios.de/comparison/comparison.html which is a website that provides a conspectus of the various source control management options currently available. The Bazaar website claims that one advantage of Bazaar over Git is that it properly handles renames of files and directories. That is important to me. I'm very particular about filenames and directory structure, and I don't want to feel that I am stuck with the first file name or directory structure I chose because changing it will confuse my version control system (or confuse the people using it). How does fossil compare to Bazaar in that regard? My understanding is that Fossil supports renames of files and directories, but does not support merges that later use the deprecated name. This is something of a race condition and might be a concern for projects with lots of disparate contributors. My own experience is that by the time a project garners lots of contributors, the basic tree structure is fairly well sussed (and for few contributors lack of this support is not that problematic). Nonetheless, providing support for intelligent renames is on Fossil's TODO list. By the way, why do these version control systems insist on a comment? Yes, I understand that commenting is good practice, but does that mean it should be mandatory and the version control system should force me to write one? I tend to think not. Fossil doesn't actually mandate that you enter a comment -- but it is generally a good idea. ___ 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] Beginners question
Quoting David tw dtw...@gmail.com: Hello all, I have two branches of my project under fossil management, trunk and stable. My intention being to perform new developments in trunk and to keep stable for releases and bug fixes. These are set up in two directories ~/project/trunk and ~/project/stable. This is not really the setup that is typically used with Fossil (or any other CMS). You want to have a directory called /project and then let Fossil handle the contents of the directory dependent upon what branch is checked out. There should be no need for you to maintain trunk and stable subdirectories (however, IF you were to do so then you would want to ensure that the stable subdirectory is not tracked in the trunk branch, and that the trunk subdirectory is not tracked in the stable branch). If you feel it is better to maintain separate trunk and stable *directories*, I would propose that you handle them as separate checkouts from the same repository. The Fossil repository itself would not contain the directories. $ mkdir trunk $ cd trunk $ fossil open /fossil_repos/project.fossil $ fossil checkout trunk $ cd .. $ mkdir stable $ cd stable $ fossil open /fossil_repos/project.fossil $ fossil checkout stable With this setup, your role as a developer would depend upon which directory you are in. This is basically what would happen if two different developers were working on the code simultaneously, one on the stable branch and one on the trunk. Whilst in directory ~/project/stable I performed a commit. To my surprise, this ended up being a commit to the trunk branch. Keep in mind that Fossil tracks whatever files that have been ADDed to the branch, regardless of where those files reside in your source tree. If you created a new stable branch by branching off of trunk then from the outset, stable will be tracking the same files that were being tracked in trunk (at the time of the branching). Unless you actually remove those trunk files (using 'fossil rm trunk/*' or somesuch), those trunk files will still be tracked during checkouts of the stable branch. ... Also there were new files included in the commit, and located in ~/project/stable, so these are also now included in trunk within fossil. My guess is that this was caused by a somewhat separate issue. A common mistake I made when starting out was to create a new branch and then assume that I was then working in that newly created branch. This is not the case. One must explicitly switch to a newly created branch (using fossil co branch). How do I correct this? Can I move the commit to stable? Or can I undo the last action? (fossil undo) You can't undo things in the sense of removing all traces of your mistake, but you can correct things by recommitting the appropriate checkouts to the appropriate branches. But you also have to fix the cause of the problem in the first place: that you have trunk files still being tracked in the stable branch -- and more importantly, that you are basically using branches incorrectly. Personally, I would recommend that you start over with a new Fossil project, and port over the files from your current project. If you want to retain the editing history then you will have to copy the files (and then commit) for each checkout in the original. This procedure is not too bad if you only have a couple dozen checkouts in the original and it will also help you detect any similar errors that have occurred previously but have gone unnoticed. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[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? bNote:/b 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 Deployment How easy is it to deploy the software? What are the dependencies and
Re: [fossil-users] Discussion of Better
Quoting Richard Hipp d...@sqlite.org: 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
Quoting Richard Hipp d...@sqlite.org: On Fri, Sep 17, 2010 at 2:50 PM, saulgo...@flashingtwelve.brickfilms.comwrote: Quoting Richard Hipp d...@sqlite.org: 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] Corrupted database
Quoting Arjen Markus arjen.mar...@deltares.nl: Hi, some further information: I am cooperating in this project with Torsten Berg and he was able to handle the repository I was not. He made a few changes, sent it back and ... I can not handle the new one either! I have no idea what is going wrong. Maybe restart the computer and try again? A while back I was experiencing similar symptoms and the problem was with my access permissions to the repository. I have since taken to creating a 'fossil' group (I'm on GNU/Linux) and authorizing everyone in that group access to the common repositories. -rw-rw-r-- 1 saul fossil 276480 2010-07-21 01:34 devilspie.fossil -rw-rw-r-- 1 saul fossil 2213888 2010-07-25 05:03 fossil.fossil -rw-rw-r-- 1 david fossil 55362560 2010-08-23 10:57 oggap.fossil -rw-rw-r-- 1 root fossil 104448 2010-08-11 01:47 pkgusr.fossil -rw-rw-r-- 1 saul fossil 33495040 2010-08-03 11:54 reva.fossil -rw-rw-r-- 1 saul fossil 138240 2010-08-18 10:58 script-fu.fossil -rw-rw-r-- 1 saul fossil 787456 2010-07-18 17:18 uwm.fossil ___ 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] Corrupted database
I was assuming (and my limited experience suggested) that the user that starts the server needs to have write access to the repository if commits are to be accepted (even if from syncing a clone). So if I (saul) wanted to commit changes to a repository created by David, I would have to start the server running as David (but I can't do that without his login password), or need to have been granted permissions to the database (which places us back at using group permissions). I suppose I could create a user dedicated to serving Fossil repos, but that is basically the same as creating a 'fossil' group (with additional steps required). If I am missing out on a better way of handling this, I would be pleased to learn about it. Quoting Michael Barrow mich...@barrow.me: Just curious why you would bother sharing the repo's through the filesystem when the HTTP method is so straightforward. On Mon, Aug 23, 2010 at 8:56 AM, saulgo...@flashingtwelve.brickfilms.comwrote: Quoting Arjen Markus arjen.mar...@deltares.nl: Hi, some further information: I am cooperating in this project with Torsten Berg and he was able to handle the repository I was not. He made a few changes, sent it back and ... I can not handle the new one either! I have no idea what is going wrong. Maybe restart the computer and try again? A while back I was experiencing similar symptoms and the problem was with my access permissions to the repository. I have since taken to creating a 'fossil' group (I'm on GNU/Linux) and authorizing everyone in that group access to the common repositories. -rw-rw-r-- 1 saul fossil 276480 2010-07-21 01:34 devilspie.fossil -rw-rw-r-- 1 saul fossil 2213888 2010-07-25 05:03 fossil.fossil -rw-rw-r-- 1 david fossil 55362560 2010-08-23 10:57 oggap.fossil -rw-rw-r-- 1 root fossil 104448 2010-08-11 01:47 pkgusr.fossil -rw-rw-r-- 1 saul fossil 33495040 2010-08-03 11:54 reva.fossil -rw-rw-r-- 1 saul fossil 138240 2010-08-18 10:58 script-fu.fossil -rw-rw-r-- 1 saul fossil 787456 2010-07-18 17:18 uwm.fossil ___ 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] Hosted fossil solution
Quoting James Turner ja...@calminferno.net: Currently I'm limiting 5 repositories per account, everything should be considered in an alpha state, but so far everything seems to be running smoothly. Let me know if you run into any issues or have suggestions. Thanks. I have registered and am attempting to learn how to work all this (I have used Fossil on remote servers on my home network but not over the Internet). One issue encountered was that my e-mail domain was flagged as invalid. I believe this was owing to it containing more than a single period (flashingtwelve.brickfilms.com). You may want to check your validation algorithm. I screwed up and did not properly note the password assigned after creating my first repository (https://chiselapp.com/user/saulgoode/repository/script-fu/) and can not log in as administrator now. If you would be so kind as to remove it when you get the chance, it would be much appreciated. I created a second repository (https://chiselapp.com/user/saulgoode/repository/script-fu-sg/) and have been able to clone it successfully; however, when I tried to PUSH some changes back (I'd disabled autosync), I received a 302 Re-direct error. I think it may be trying to re-direct from HTTP to HTTPS but I am not sure (if I use the HTTPS URL then Fossil reports that it does not support HTTPS). It is quite possible that I am doing something wrong at this point as I am inexperienced at using some of Fossil's multi-user features. Thank you for the opportunity to use your hosting. I will spend more time experimenting tomorrow but if there is anything you wish me to try, please ask. Regards. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Accessing original check-in
I have encountered a problem which is in a way trivial, but it is also
somewhat important to me.
THE PROBLEM
After creating a new repository and opening it, 'status' displays that
it has been assigned a 'checkout' identifier; however, I am never able
to access that 'checkout'. If I create a new branch off that origin,
when I try to return to 'trunk', I receive a not a check-in error
(I've included a transcript of a test session at the end of this post).
MY GOAL
I wish to use Fossil to maintain a directory of scripts and I would
like to start a new branch whenever I create a new script, and to have
that branch contain only the script file. In other words, if 'root' is
the original empty check-in artifact, I want each script to be a
branch off of 'root' (the scripts would be merged back to 'trunk').
A WORK-AROUND
If I first check-in a commit to trunk that includes an ADDed file
(even an empty one), I can then use the original check-in ('root') for
starting branches -- successfully being able to merge those branches
back to trunk. I can even later delete the empty-file and remove it
from 'trunk'.
WHY WORK-AROUND IS UNSATISFACTORY
Though the above work-around completely satisfies my personal needs, I
am hoping to introduce some absolute beginners -- to both programming
and Source Configuration Management -- to using Fossil to organize
their programming activities. It is less than ideal that amongst the
very first steps in getting started, it is necessary to perform a
somewhat unintuitive work-around (it wouldn't be so bad if it came
later in the course).
CONCLUSION
While my goal is admittedly an edge case, and branching off an empty
check-out may be rather unintuitive itself, I do think this behavior
is somewhat anomalous and should probably be considered a bug. The
original check-out is assigned an ID and one is able to branch from
that ID, yet it is otherwise not recognized as a valid check-out of
'trunk'.
This is by no means critical, but it did seem worth mentioning. If
anybody has any suggestions for simpler work-arounds -- or maybe I
missed something completely obvious -- please let me know.
--
TRANSCRIPT OF TEST SESSION
$ fossil new $HOME/foo.fossil
project-id: 22cc9378e7e9c90aa69ab5de4d2158082e2b84c5
server-id: 4e110fd69e6c808f9b4b77da3450a674e51d0a5e
admin-user: saul (initial password is 004d85)
$ fossil open $HOME/foo.fossil
$ fossil status
repository: /home/saul/foo.fossil
local-root: /home/saul/test/
server-code: 4e110fd69e6c808f9b4b77da3450a674e51d0a5e
checkout: ed9081561d84e261b5a0f3aaf0531fdb530feb57 2010-07-26
21:57:18 UTC
tags: trunk
$ fossil branch new bar trunk
New branch: aa562d8538bbdfa72c44dbf3a8cd14d1925d6db1
$ fossil co bar
$ touch empty-file
$ fossil add empty-file
ADDED empty-file
$ fossil commit
New_Version: d5a946e783821ce9a79866e13f920ec02a092f31
$ fossil co trunk
fossil: object [ed9081561d] is not a check-in
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
