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
> > 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
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
ven >> 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? What I was thinking of may not be that practical, but in certain situations it would be really valuable. I guess what I was asking for was an annotate that works like a diff --from --to with that done for every changeset from the beginning of time or for some range of time. Even better would to have a diff --from --to with a keyword search so you get every possible version-to-version diff that has the search string present. Invaluable for working on huge source files that have been in maintenance mode for years. Ideally, it would be neat to have 2-up diffs of every change set in some range. I know in the past I have had to scour output from many versions to see where something went wrong, for example if a problem is reported from the field and looking at the source we realize it couldn't have worked in this version, and not the previous version, and not the one before that, etc. How far back do we have to go? When did we break this and when is the last time it worked? It helps to have a way to compare sections of code over time...so an annotate in diff form would be invaluable. If this isn't already available I guess it could be scripted without messing up the fossil code, even externally scripted. Thank you for the information and two great products! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Thanks and some questions
Hi I have been using Mercurial for my own small projects and am mostly satisfied with it from a perspective of using it. I don't like that it uses Perl scripts and other pieces to do what it does. I really like the fossil and sqlite design having one standalone executable and no dependencies. Outstanding! Big thanks to Dr. Richard and the devs for both sqlite and fossil. I am moving towards using fossil for all my version control. All of my development is either single developer or very small team. 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? 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. 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? I would like to be able to quickly identify what I have done to a file all throughout its history. Thanks to everyone! _______ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
