Re: [fossil-users] Thanks and some questions
To see the list of unmanaged files: Thank you. It is more manual than I was looking for but if that's the way it works that's the way it works. Beware of any program that thinks it knows more than you do. -- D. Richard Hipp Point taken, but that isn't what I've been wondering about and anyway isn't doing clerical tasks better than humans exactly the sort of thing software should do? In other words we're forgetful and make mistakes. I don't suggest automagically adding everything and anything but flagging them does seem prudent and helpful without going over the line and actually making a decision for us. Especially if the globbing exclude (perhaps you can do globbing includes as well) is set it seems safe to at least put out a prompt and we can answer all, none, yes or no to each in the list. Something like that *might* be good. fossil already alerts us when a file you said to manage isn't in the directory for change, stat, commit (maybe others, haven't come across it yet). Why isn't the converse done automagically? It's not symmetric right now. It seems reasonable change, stat, and commit would flag files in the managed directory tree that aren't managed. Is that helpful or does it become like the endless Windows OK prompts? ___ 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] Thanks and some questions
Depending on if your files fit a nice set of patterns you may want to consider using ignore-glob to keep from seeing your irrelevant files. The methodology I encourage on our team is that a fossil extras should always be clean, i.e. there should be no extras. That sounds like a good idea. Any extras should be either added to fossil with fossil add or added to the glob list. Good point. To make that a bit easier we use the .fossil-settings/ignore-glob file instead of the setting via the ui. Don't forget to fossil add the .fossil-settings/ignore-glob file. Thanks, I'll have a look at this. We commonly have one or more build directories where various processes are run and ignore them all with a */build/* pattern or similar. However do be careful with blanket ignores. If I recall correctly fossil behavior is a little odd when it comes to controlled files that match an ignore pattern. I seem to remember that a modified controlled file masked by a ignore does not show up in fossil status Thanks for the tips, this is the kind of advice I was hoping 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] Thanks and some questions
On Mon, Mar 19, 2012 at 4:12 AM, mail...@nym.mixmin.net wrote: [snip] I often add programs to the project and I don't always remember to tell fossil about them. What is the correct way to use fossil so when you work on new projects where you don't have everything that will ultimately be part of the project in your directory from the beginning? What should I be doing to make sure fossil knows about all the new code? add doesn't seem to work, and stat or chan doesn't flag newly created files that I haven't already added. This is a bit disturbing and I'm afraid new modules will go untracked. I find myself using add * or addr. addr should usually be ok but I don't like taking the chance to delete something. I realize unless you shun nothing is actually lost but I don't know how it works and what problems I could cause by addr. My question is really how should I be doing this workflow. I think you want the fossil extra command to tell you what files are in your working folder that are not under management. And the fossil addremove command which will recursively descend through your working folder adding and removing files as necessary so that everything is under management again. Thanks, I missed the extra command, that sounds helpful but I guess what I would have preferred, since it doesn't take any extra action on the users's part, might be to see all the files that exist that aren't managed, when I do fossil stat or fossil change. In other words I'm looking for something that goes out of its way to tell me hey, do you realize you have new files here that fossil isn't managing? Specifically this happens to me a lot because I'm doing some work right now on text processing and I have a lot of junk files in my working directories I use as input for my tests. I don't tend to want to manage this stuff because I can grab more text and create new test cases easily. If I do fossil addr all the time I find tons of crap gets added and deleted from the repo and that bothers me since it shouldn't have been there at all and it just gets dragged along because I don't have a way to be notified when I add source code that I *do* want managed. Either I keep doing addr (or now extra and figure it out manually) and get my source and junk files added, or I lose the junk and the new source code because I don't always remember what's been added and what hasn't. I guess I need to get used to managing the tools more than I have been. In the past I worked on established products and we almost never added new source files. Now I am writing a lot more code and need to rethink how I am managing that process. Depending on if your files fit a nice set of patterns you may want to consider using ignore-glob to keep from seeing your irrelevant files. The methodology I encourage on our team is that a fossil extras should always be clean, i.e. there should be no extras. Any extras should be either added to fossil with fossil add or added to the glob list. To make that a bit easier we use the .fossil-settings/ignore-glob file instead of the setting via the ui. Don't forget to fossil add the .fossil-settings/ignore-glob file. We commonly have one or more build directories where various processes are run and ignore them all with a */build/* pattern or similar. However do be careful with blanket ignores. If I recall correctly fossil behavior is a little odd when it comes to controlled files that match an ignore pattern. I seem to remember that a modified controlled file masked by a ignore does not show up in fossil status I am not criticizing fossil (it's great!), I am just trying to understand how to use it efficiently for the way I work, rather than trying to adjust the way I work for the benefit of the scm I'm using. In the end I will probably have to do a little of both. For me this is the flip side of fossil telling you if you had a file under management and you deleted it, when you do a stat, changes, or commit. That works great and gives a red flad- hey, I can't find file a and file b. Then again, I admit what I was thinking of may bring problems with it because if you have ignored dozens or hundreds of files when you do a stat or changes or commit you don't want to see those. Maybe that logic already exists. After I hear your comments I'll try to work with this more and get a better understanding. But I am also interested in hearing how people who are writing a lot of new code and also keep test and other junk in the project directory tree are using fossil. [snip] ___ 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] Thanks and some questions
I wrote about some of the other issues you addressed in another post. What should I be doing to make sure fossil knows about all the new code? add doesn't seem to work, and stat or chan doesn't flag newly created files that I haven't already added. fossil add file fossil commit -m 'foo' file :-? I realize that but I was hoping for some help from fossil. For example when you delete a file fossil was managing and you do a changes, stat or commit fossil tells you the file is gone. I was looking for that same function to also provide the oppposite info, letting you know there are new files that haven't been added. To see the list of unmanaged files: fossil extra Thank you. It is more manual than I was looking for but if that's the way it works that's the way it works. ___ 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] Thanks and some questions
On Sun, Mar 18, 2012 at 12:10 PM, mail...@nym.mixmin.net wrote: I notice the .fossil file is created in my home directory when using fossil. Because I am testing how fossil works to learn how to use it for my workflows, I have created several fossil repos for different test projects and then sometimes delete the whole subdirectory containing the repo when I am done testing. Does this cause anything to be orphaned inside the .fossil file in home directory? How do I to tell fossil to clean up this file and let fossil know the repo(s) I was testing with have been deleted? Orphan entries are created in the .fossil database. But they are small. And they are automatically cleaned up the next time you run the fossil all command. I often add programs to the project and I don't always remember to tell fossil about them. What is the correct way to use fossil so when you work on new projects where you don't have everything that will ultimately be part of the project in your directory from the beginning? What should I be doing to make sure fossil knows about all the new code? add doesn't seem to work, and stat or chan doesn't flag newly created files that I haven't already added. This is a bit disturbing and I'm afraid new modules will go untracked. I find myself using add * or addr. addr should usually be ok but I don't like taking the chance to delete something. I realize unless you shun nothing is actually lost but I don't know how it works and what problems I could cause by addr. My question is really how should I be doing this workflow. I think you want the fossil extra command to tell you what files are in your working folder that are not under management. And the fossil addremove command which will recursively descend through your working folder adding and removing files as necessary so that everything is under management again. Another question is on annotate. When I use annotate I see the change history for a file. But if only one line of the file was changed repeatedly it seems I don't see the change for each commit, only the last value. Is this right and is there a way to show all the changes done to one file even if it's all the same line, maybe with diffs from one commit to the next? The fossil annotate command is modeled after cvs annotate, which only shows the most recent change for all current lines in the file. Can you show us an alternative display format that shows all historical changes to a file? What does hg do? ___ 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
