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
On Mon, Mar 19, 2012 at 4:00 PM, wrote: > > > > fossil extra > > > 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 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] 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 Mon, Mar 19, 2012 at 4:12 AM, 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
Re: [fossil-users] Thanks and some questions
>> 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. Thanks, good to know! >> 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. 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. >> 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? What I was thinking of may not be that
Re: [fossil-users] Thanks and some questions
On Sun, Mar 18, 2012 at 12:10 PM, 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
Re: [fossil-users] Thanks and some questions
On Sun, Mar 18, 2012 at 5:10 PM, wrote: > I notice the .fossil file is created in my home directory when using > fossil. It will create it wherever you tell it to. e.g.: fossil new /tmp/foo.fossil mkdir ~/foo cd ~/foo f open /tmp/foo.fossil Then ~/foo is your checkout and the repo is /tmp/foo.fossil. The relationship is one-way: the checkout knows about the repo but not the other way around. > 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? > You don't need to do anything - the main fossil file doesn't know about the checkouts. Each checkout maintains a local _FOSSIL_ file which is another sqlite3 which holds metadata which is automatically generated from the main repo. It also holds your local stash, update undo, and such. > I often add programs to the project and I don't always remember to tell > fossil about them. Don't worry - fossil never knew 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. fossil add file fossil commit -m 'foo' file :-? To see the list of "unmanaged" files: fossil extra 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! > This is how annotate works (it's not a bug). There currently is no feature to display ALL changes from ALL versions at one time (and i can't imagine how that would be readable). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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
