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
