It has its pros and cons. Most important ones I see:
+ Common files will only be stored once (having the same SHA) so overall
size of repos is smaller than the total of separate repos, one for each
project.
- If common files change, you need to merge changes to each project
separately, making it a bit tedious, especially as the number of projects
grows.
- Keeping too many (large) projects may make the single repo file extremely
large and difficult to transfer or to backup.
- You cannot split out a project at a later time (wish list). So, you're
stuck with this arrangement for good.
Multi-project repos is a very useful use case. All my repos are such. This
is mostly a necessity by the fact all these projects share code in one way
or another, and there is no convenient alternative for this.
Just a few related ideas to add to the wish list:
* As hinted above, it would be nice if FOSSIL could create a new repo from
another repo's existing branch (or branch set). So, if I want to separate a
project to a new repo (either because of size, or simple because I want to
make just one project a separate repo for publishing), I could somehow
create a new repo by extracting a branch set from a previous repo.
* It would be nice if FOSSIL allowed for a special kind of branch that would
be common to all other branches. So, that all common code (libraries, etc.)
could be placed in that one branch and then this branch would be checked out
with any other branch checkout, and updated the same way. So, making a
change to files belonging in that common branch would ultimately affect all
projects without any further action.Opening a branch would open the
actual branch plus the common branch as the two were one. Obviously, it
cannot be allowed that files (paths) belonging in common branch are also
part of the normal branch, or the other way around.
* People wanting to come to FOSSIL from other systems (with the exception of
git for which there is an import feature) have to wait for a new project if
the want to keep the full history of changes, or go through a very tedious
and time consuming process of manually generating the repo to look as if it
was used from the beginning of the project. (To get an accurate result, you
need to fiddle with the system clock to pretend you're committing at an
older date/time. Although fossil's concept is to have an immutable repo
(and I completely agree with that), so there can't be a way to add history
after the repo has been used a bit, there should be some method to create a
fresh repo (or timeline) from existing files in a chronological order
(either according to the file's date/time stamp, or by some explicit
date/time option), and the result should be as if the repo (or timeline) was
actually created over time. This action should only be allowed once on a
fresh empty repo or initial commit. For example, the user places all
historic file sets (commits-to-be) in distinct subdirectories, and then
FOSSIL via a special command (again, to be allowed only once per initial
empty commit), goes over each subdirectory recursively, putting the contents
in an automatically generated 'commit' (and a relevant comment like 'auto
commit') using as date the most recent file's date of the respective
subdirectory. After the first automatic commit is processed, the rest of
the history should be treated the same way as manual commits, as if the user
had done an 'addremove .' followed by 'commit'.
Tony P.
-Original Message-
From: Vikrant Chaudhary
Sent: Tuesday, January 27, 2015 2:37 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Repo with many initial commits
I personally think that fossil open --empty is a pretty good
strategy to keep multiple projects in the same repository.
Cheers.
- Vikrant
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
