Would it make sense to add some support for ignoring sub-trees that contain other version control systems? I'm running into having git and subversion trees in my fossil check-outs, and some commands become slightly painful and annoying.

It would I suppose maybe be off by default, but the option would be nice.

It would I suppose maybe be off by default, but the option would be nice.

It would be a maintenance nightmare for us. As soon as we support exclusion of one SCM, someone would demand that we support some other SCM, and the list of available SCMs is still growing.

You can hypothetically exclude such sub-trees from potentially painful commands by adding them to your ignore-globs setting.

You can hypothetically exclude such sub-trees from potentially painful commands by adding them to your ignore-globs setting.

I was going to say: I must be missing something because I would've thought this is a case for putting .git or whatever you want ignored in .fossil-settings/ignore-glob.

Does that not satisfy your use case?

No, since that does not ignore what .git tracks (i.e., git's checkout)

No, since that does not ignore what .git tracks (i.e., git's checkout)

Why not ignore the whole directory with a glob like my-git-checkout/*?

Because I'd need to do that for every checkout of "other" VCS. Seeing that Fossil already does it for it self, I don't think it is far fetched that it did for others.

Because I'd need to do that for every checkout of "other" VCS.

One ignore-glob per sub-checkout seems like a small price to pay for this fringe use case.

Applying this feature built-in to fossil affects not only your project but imposes a performance hit on every fossil checkout because almost every file/directory-related check would have to ensure that none of the directory components in any given path are believed to be owned by another SCM.

For example, if a user provides filename a/b/c/d/e.f, fossil would have to check for a/.git, a/b/.git, a/b/c/.git, a/b/c/d/.git, and the equivalent for every other SCM, for very nearly every operation which refers to a file which fossil does not already explicitly know about.

If you will provide concrete examples of commands which are causing you grief, perhaps we can suggest alternatives, but it sounds like what you want to do is already accounted for by the ignore-glob feature.

One ignore-glob per sub-checkout seems like a small price to pay for this fringe use case.

It doesn't even need to be per subcheckout. You could only have this on the ignore-glob:

   .git/*
   */.git/*

To ignore all the .git directory and their content in your repo.

I still do not get it, you make it too complex. Would you explain it for the five-year-old in me? Maybe draw an ASCII tree?

project/.fslckout
       /gcc-x86_64-redhat-linux-gnu-10.0/.svn
                                        /bin/x86_64-redhat-linux-gnu-gcc
       /gcc-powerpc-unknown-linux-gnu-2.95/.svn
                                          /bin/powerpc-unknown-linux-gnu-gcc
       /third-party-module-one-1.2.3/.git  -- used only by powerpc
       /third-party-module-one-2.3.4/.git  -- used only by x86_64
       /third-party-module-three-1.2.3/.git
                                      /third-party-submodule-three-1.2.3/.git
       foo.vhdl
       foo.c

The major reason why we do it like this is so that we can bundle everything up into a single archive at the end of the project, and leave it for 10 years, in case we need to reproduce something for a customer. There can be several dozens of third parties (can be internal, or external).

The second reason is that it makes it trivial to switch versions when one needs to.

project/.fslckout

ignore-glob = gcc-*, third-party-*

Certainly you're not arguing that that's a huge maintenance burden? The above is clear and straightforward and does not involve untold numbers of hours of development and testing and ongoing maintenance in fossil's C code. Nor does it impose any I/O performance hit on other users like your request would.

The I/O performance hit mentioned earlier for checking for '.git' (and SVN and CVS and mercurial and Sapling, etc) would be huge on a tree which contains whole copies of gcc and other massive tools. A glob, on the other hand, still has a performance hit for such a massive tree but it doesn't have an I/O hit (I/O being the slowest component, generally speaking).

a fossil project that uses other git projects

Why do they have to share a tree?

I use this scheme:

  ~/src/extprj/branch     ← external projects built from source
  ~/lib, ~/include        ← dev-only libraries installed from above
  ~/src/myprj/branch      ← my project linked to above

Not everything gets installed to --prefix=$HOME. Some things go to global directories, depending on how they're used.

Regardless, I use "make install" to well-known directories as the mechanism by which multiple projects are combined, not nested subtrees of VCS repos.

The only exceptions are things like SQLite, which are bodily included into the ~/src/mine/branch trees and tracked along with all the other files in that project.

Why do they have to share a tree?

Because that is what we do, prefer and have been doing for years.

Workflows are workflows, changing them is not something that can be done without havoc.

You can justify anything with that argument.

If you're going to resist logical solutions, you'll either have to take the bad with the good, as you find it, or you'll have to do the work to support your idiosyncratic workflow yourself.

That is unfriendly and uncalled for. There is literally nothing logical with trying to change a whole organizations workflow just cause YOU dislike the workflow.

We patched our local fossil to simple handle .git and what not as it does for .fslckout.

No, since that does not ignore what .git tracks (i.e., git's checkout)

Hence the: this is a case for putting .git or whatever you want ignored in .fossil-settings/ignore-glob.

I am not sure that I agree that it would be a nightmare, there aren't that many VCs, and their semantic doesn't change that often (it would be less work than updating for each SQLite version).

But ...

It might be possible to make this generic, that is ... being able to specify a pattern that excludes the content as well, e.g., if you say "ignore-glob-with-directory-content .git". That would ignore any directory that contains .git, but also whatever lives in that directory (RCS/CVS you'd add RCS or CVS, for SVN you add .svn or whatever it uses).

This would work for I think every single version control system ever created (fetches hat to eat in case that is not the case). Of course, someone would have to do the work ... not volunteering sadly. :-(

I just use a bare git repository for the mirror of the fossil repository, rather than trying to put more than one kind in the same directory which seems to me like it would make a mess. Furthermore, I do not add files automatically, instead using fossil add to add files manually that should be included in the repository. At least to me, I think this is better.