Re: [fossil-users] Multiple Projects in one Repo

[Sergei Gavrikov]

On Thu, 16 Sep 2015, Andy Bradford wrote:

> Thus said Oliver Friedrich on Sat, 12 Sep 2015 12:34:21 -:
>
> > What I  really would  like to  have is to  gather multiple  such small
> > projects in  one repo file,  so instead  of having one  ROOT check-in,
> > having one  ROOT for each project.  I know that would  make developing
> > fossil a bit harder, but I think  it would be a great feature and that
> > not I'm the only one who would use this.
>
> You  mean like  this: assume  you  have two  Fossils, master.fossil
> and project.fossil. You  want to combine  the projects into a  single
> Fossil but retain an independent timeline for each:
>
> $ echo "SELECT 'UPDATE config SET value = ''' || value || ''' WHERE name = 
> ''project-code'';' FROM config WHERE name = 'project-code';" | fossil sql -R 
> master.fossil | fossil sql -R project.fossil
> $ fossil pull --once -R master.fossil project.fossil
>
> Now, master will have two independent timelines, one from each project.
> Here's an example:
>
> http://fossil.bradfords.org:8080/timeline

Very nice concept and solution. Thank you for Fossil SQL sugar and
on-line demo!

Sergei
___
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] Multiple Projects in one Repo

[Oliver Friedrich]

Finally, I found a solution to satisfy my needs. I started a repository
with multiple independent branches. I do checkout the branches as
subdirectories below the trunk checkout with nested checkout. It is a bit
more effort to set things up, but simple scripts can help for that.

Adding branches goes relatively straight with:
branch-add-nested.sh:
---
#!/usr/bin/env bash
repo=$(fossil info | grep repository | awk 'BEGIN{FS=" "} {print $2}')
mkdir -p "$1"
pushd "$1"
fossil open --empty --nested "$repo" "$1"
fossil commit --branch "$1" --allow-empty -m "initial empty check-in"
popd
--

Checking out from closed repository with a bash-for loop is rather simple
as well:

ckout-nested.sh
-
#!/usr/bin/env bash
repo=$(fossil info | grep repository | awk 'BEGIN{FS=" "} {print $2}')

if [ ! -e .fslckout ]; then
echo "Not in a fossil checkout" 1>&2; exit 1;
fi

for b in `fossil branch ls| grep -v trunk`; do {
mkdir -p "$b"
cd "$b"
fossil open --nested "$repo" "$b"
cd ..
}
done;


Maybe I will take some time to enhance the web-frontend a bit to keep
things separated there, but for the first, this will do for me.


Warren Young  schrieb am Do., 17. Sep. 2015 um 20:06 Uhr:

> On Sep 16, 2015, at 10:02 PM, David Mason  wrote:
> >
> > On 16 September 2015 at 21:56, Steve Stefanovich  wrote:
> > ‎Isn't the main annoyance the need to commit two times, one in nested
> checkout and one in the 'root' repo, and to try to keep timeline order in
> both?
> >
> > How do you guys manage that - prevent committing/cloning to root and
> always use sub-repos?
> >
> > There's only one commit, in the sub-repo, unless I change something in
> the root repo, but that's pretty rare for me.
>
> My use of nested repos is similar: the nested one is rarely-modified, so
> the problem doesn’t affect me.
>
> From my reading of the Git book section previously linked, it looks like
> this is a mostly manual operation in Git, too, though it has optional flags
> that can make it do nested commits and such.
>
> I can see cases where you might *want* it to be manual, as when the
> submodule is an external dependency, and you want to “pin” your project to
> a particular version.
>
> But in other cases, it would be nice if a commit or update at the root did
> the same for all submodules, recursively, every time.  It would be
> analogous to the current autosync setting: sometimes you want it, sometimes
> you don’t.
> ___
> 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

Re: [fossil-users] Multiple Projects in one Repo

[Warren Young]

On Sep 16, 2015, at 10:02 PM, David Mason  wrote:
> 
> On 16 September 2015 at 21:56, Steve Stefanovich  wrote:
> ‎Isn't the main annoyance the need to commit two times, one in nested 
> checkout and one in the 'root' repo, and to try to keep timeline order in 
> both?
> 
> How do you guys manage that - prevent committing/cloning to root and always 
> use sub-repos?
> 
> There's only one commit, in the sub-repo, unless I change something in the 
> root repo, but that's pretty rare for me.

My use of nested repos is similar: the nested one is rarely-modified, so the 
problem doesn’t affect me.

From my reading of the Git book section previously linked, it looks like this 
is a mostly manual operation in Git, too, though it has optional flags that can 
make it do nested commits and such.  

I can see cases where you might *want* it to be manual, as when the submodule 
is an external dependency, and you want to “pin” your project to a particular 
version.  

But in other cases, it would be nice if a commit or update at the root did the 
same for all submodules, recursively, every time.  It would be analogous to the 
current autosync setting: sometimes you want it, sometimes you don’t.
___
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] Multiple Projects in one Repo

[Steve Stefanovich]

‎Isn't the main annoyance the need to commit two times, one in nested checkout 
and one in the 'root' repo, and to try to keep timeline order in both?

How do you guys manage that - prevent committing/cloning to root and always use 
sub-repos?


  Original Message
From: Warren Young
Sent: Tuesday, 15 September 2015 03:58
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Multiple Projects in one Repo


On Sep 12, 2015, at 9:54 AM, Oliver Friedrich 
<redtalonof+mailingl...@gmail.com> wrote:
>
> with nested repositories my administration overhead would exceed even the 
> single repository solution, right?

The alternative to managing just one .fossil file is managing just one directly 
full of .fossil files.  Is that really such a big difference?

Note that “fossil serve” works the same when pointed to a directory full of 
fossils as it does when pointed at a single fossil, with the exception that the 
URLs are all one directory deeper.

There are two annoyances currently involved in managing nested repositories, 
which could in principle go away: the need to explicitly open the 
sub-repositories every time you open the primary, and the need to pass --nested 
to bypass the checks Fossil does for a parent containing .fslckout (a.k.a. 
_FOSSIL_).

Git solves this problem more elegantly with the submodule:

  https://git-scm.com/book/en/v2/Git-Tools-Submodules

In short, the main project simply declares that it needs other projects by URL. 
When you clone the main project, Git also clones the submodules into the 
correct place within the parent’s tree.

I use nested checkouts myself, though probably for a different reason than 
you’re proposing.  I have a top-level repository with many branches for older 
versions of the software, and all versions need to share a single set of 
Fossil-managed resource files.  These shared resource files must be versioned 
separately from the main repository files, but the current version must always 
be present underneath the main repository branches.  If I have three branches 
checked out, I need three additional nested checkouts of the shared repository.

It would be very nice if I could just open each branch, and have the 
subproject’s repo opened in its correct place, automatically.
___
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

Re: [fossil-users] Multiple Projects in one Repo

[Andy Bradford]

Thus said Oliver Friedrich on Sat, 12 Sep 2015 12:34:21 -:

> What I  really would  like to  have is to  gather multiple  such small
> projects in  one repo file,  so instead  of having one  ROOT check-in,
> having one  ROOT for each project.  I know that would  make developing
> fossil a bit harder, but I think  it would be a great feature and that
> not I'm the only one who would use this.

You  mean like  this: assume  you  have two  Fossils, master.fossil  and
project.fossil. You  want to combine  the projects into a  single Fossil
but retain an independent timeline for each:

$ echo "SELECT 'UPDATE config SET value = ''' || value || ''' WHERE name = 
''project-code'';' FROM config WHERE name = 'project-code';" | fossil sql -R 
master.fossil | fossil sql -R project.fossil
$ fossil pull --once -R master.fossil project.fossil

Now, master will have two independent timelines, one from each project.

You'll then  want to  rename one  of the  trunks (and  maybe give  it an
intentional color  too) in  one of  the timelines  to something  else or
you'll get a warning about there being  two open leaves with the name of
trunk (even though technically there really isn't a fork in this case).

> But I  guess that implementing  this could be much  harder, especially
> visualizations in the web-frontend.

The web-frontend can handle visualizing this just fine I think. What may
take some getting used  to is that the files and  checkins will not have
common ancestors.

Also,  if  you   have  the  same  exact  filename  (and   path)  in  one
``sub-project''  that exists  in another,  the Files  display in  Fossil
might be tricky to navigate. But otherwise, it will probably work well.

Here's an example:

http://fossil.bradfords.org:8080/timeline

But, the same filename exists in  all three timelines, but has different
content. Files only shows the last (due to tip):

http://fossil.bradfords.org:8080/dir?ci=tip

You could  certainly change  the Header  to have  multiple links  to the
various files of a given ``sub-project'' like:

Trunk Files: http://fossil.bradfords.org:8080/dir?ci=trunk
Project1 Files: http://fossil.bradfords.org:8080/dir?ci=project1
Project2 Files: http://fossil.bradfords.org:8080/dir?ci=project2

What if you need  files from different projects at the  same time in the
same tree?  Well, you'll  have to  resort to  multiple opens  (and maybe
--nested) for that.

Andy
-- 
TAI64 timestamp: 400055fa4bb3


___
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] Multiple Projects in one Repo

[David Mason]

On 16 September 2015 at 21:56, Steve Stefanovich  wrote:

> ‎Isn't the main annoyance the need to commit two times, one in nested
> checkout and one in the 'root' repo, and to try to keep timeline order in
> both?
>
> How do you guys manage that - prevent committing/cloning to root and
> always use sub-repos?


There's only one commit, in the sub-repo, unless I change something in the
root repo, but that's pretty rare for me.

../Dave
___
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] Multiple Projects in one Repo

[David Mason]

On 14 September 2015 at 13:58, Warren Young  wrote:

> On Sep 12, 2015, at 9:54 AM, Oliver Friedrich <
> redtalonof+mailingl...@gmail.com> wrote:
> >
> > with nested repositories my administration overhead would exceed even
> the single repository solution, right?
>
> The alternative to managing just one .fossil file is managing just one
> directly full of .fossil files.  Is that really such a big difference?
>
> Note that “fossil serve” works the same when pointed to a directory full
> of fossils as it does when pointed at a single fossil, with the exception
> that the URLs are all one directory deeper.


I use nested checkouts and I have many .fossil files in my ~/Fossils
directory.  One of them, Admin, has a wiki page that points to pages in the
others so I can access them easily.  I keep the url
http://localhost:8080/Admin/wiki?name=Admin open in one of my browser tabs
(actually the first one) so I can easily get at any of the repos in one
click.  I have sections in that wiki page like:

Direct Links
  *  Courses Links
  *  CPS313 Links

Administrative links
  *  Courses
  *  Research

along with other generally useful links.

Yes, I have to use --nested when I open a new directory on a repo, but I do
that only a few times a year (in fact, I usually forget, but fossil tells
me there's a problem, so I re-issue the open with --nested).

../Dave
___
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] Multiple Projects in one Repo

[Warren Young]

On Sep 12, 2015, at 9:54 AM, Oliver Friedrich 
 wrote:
> 
> with nested repositories my administration overhead would exceed even the 
> single repository solution, right?

The alternative to managing just one .fossil file is managing just one directly 
full of .fossil files.  Is that really such a big difference?

Note that “fossil serve” works the same when pointed to a directory full of 
fossils as it does when pointed at a single fossil, with the exception that the 
URLs are all one directory deeper.

There are two annoyances currently involved in managing nested repositories, 
which could in principle go away: the need to explicitly open the 
sub-repositories every time you open the primary, and the need to pass --nested 
to bypass the checks Fossil does for a parent containing .fslckout (a.k.a. 
_FOSSIL_).

Git solves this problem more elegantly with the submodule:

  https://git-scm.com/book/en/v2/Git-Tools-Submodules

In short, the main project simply declares that it needs other projects by URL. 
When you clone the main project, Git also clones the submodules into the 
correct place within the parent’s tree.

I use nested checkouts myself, though probably for a different reason than 
you’re proposing.  I have a top-level repository with many branches for older 
versions of the software, and all versions need to share a single set of 
Fossil-managed resource files.  These shared resource files must be versioned 
separately from the main repository files, but the current version must always 
be present underneath the main repository branches.  If I have three branches 
checked out, I need three additional nested checkouts of the shared repository.

It would be very nice if I could just open each branch, and have the 
subproject’s repo opened in its correct place, automatically.
___
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] Multiple Projects in one Repo

[Ron W]

On Sat, Sep 12, 2015 at 8:34 AM, Oliver Friedrich <
redtalonof+mailingl...@gmail.com> wrote:

>
> My current solution is to have one repository with an empty initial
> check-in tagged as ROOT. Then I do one branch per sub-project based on the
> ROOT check-in.
>
> That way I'm able to keep my code cleanly detached from each another, but
> it feels really dirty - cause that's in no way the correct handling of
> branches.
>
> What I really would like to have is to gather multiple such small projects
> in one repo file, so instead of having one ROOT check-in, having one ROOT
> for each project. I know that would make developing fossil a bit harder,
> but I think it would be a great feature and that not I'm the only one who
> would use this.
>

It is already possible to create multiple "initial, empty check-ins" (aka
"ROOT", if you really want to do that. However, be default,  each one would
have it's own "trunk". To avoid confusion, you would need to rename them.

What you are doing, a "main branch" for each project, is probably the
simplest, cleanest way.

(Nested projects are usually most useful for when you have 1 or more shared
sub-projects. Not really applicable to your situation.)
___
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] Multiple Projects in one Repo

[Richard Hipp]

On 9/12/15, Oliver Friedrich  wrote:
>  I have bunch of code-samples and abstracted code-problems in
> different programming languages and flavours, that I keep as personal
> knowledge database. I tend to give each of them its own fossil repository,
> but as I mentioned before, sometimes they have just one or two files.
>
> What would be your approach on my problem?
>

I keep all of my person notes like this in a single Fossil repository
that I call "toolbox.fossil".  It does not change that often (my
toolbox averages 8 or 9 check-ins per year for the previous 7 years),
so it does not really matter that it is a big jumble of one- and
two-file projects and code snippets.

-- 
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] Multiple Projects in one Repo

[Oliver Friedrich]

If I get your script right, then I would have one fossil repository for
each sub-project and one for the top-project. So with nested repositories
my administration overhead would exceed even the single repository
solution, right?

Johan Kuuse  schrieb am Sa., 12. Sep. 2015 um 16:27 Uhr:

> Hi,
>
> After some suggestions in this ML, I chose using nested repositories.
> The "root repository", which I called 'nested', only contains a few files.
> All other repositories are open inside the 'nested' directory, with the
> -nested option.
>
> Here is a script which clones, opens and updates the entire nested
> directory tree (fossul-setuo.sh):
>
> http://kuu.se/fossil/nested.cgi/doc/tip/index.html
>
> Just my two cents to give you an idea...
>
> BR,
> Johan
> El 12/9/2015 14:44, "Michai Ramakers"  escribió:
>
>> Hello,
>>
>> On 12 September 2015 at 14:34, Oliver Friedrich
>>  wrote:
>> > I want to give a thought on how I use fossil regularly and on what I
>> would
>> > love as a feature.
>> >
>> > While fossil is easy to set up and maintain, I often have several small
>> > projects that seem to be to small to get an own instance of a
>> repository for
>> > themselfes. Additionally, I like to use fossil, because it reduces the
>> > number of files to manage (1 repo instead of dozens of files per
>> project).
>> >
>> > That spoken, I have bunch of code-samples and abstracted code-problems
>> in
>> > different programming languages and flavours, that I keep as personal
>> > knowledge database. I tend to give each of them its own fossil
>> repository,
>> > but as I mentioned before, sometimes they have just one or two files.
>> >
>> > My old solution was to have one repository with one set of folders for
>> each
>> > sub-project. But Timeline get messy really fast and it is hard to track
>> > sub-projects with this approach.
>> >
>> > My current solution is to have one repository with an empty initial
>> check-in
>> > tagged as ROOT. Then I do one branch per sub-project based on the ROOT
>> > check-in.
>> >
>> > That way I'm able to keep my code cleanly detached from each another,
>> but it
>> > feels really dirty - cause that's in no way the correct handling of
>> > branches.
>> >
>> > What I really would like to have is to gather multiple such small
>> projects
>> > in one repo file, so instead of having one ROOT check-in, having one
>> ROOT
>> > for each project. I know that would make developing fossil a bit
>> harder, but
>> > I think it would be a great feature and that not I'm the only one who
>> would
>> > use this.
>> >
>> > In the simpliest logic I can imagine this would mean nothing more than
>> one
>> > additional layer, branches belong to project. For the normal use, each
>> > branch would just belong to the default project. But I guess that
>> > implementing this could be much harder, especially visualizations in the
>> > web-frontend.
>> >
>> > But what do you think about multiple projects in one repo?
>> > What would be your approach on my problem?
>>
>> I think this has come up a few times on this ML; I think some
>> suggestions are to use nested repos ('fossil open --nested') or
>> indeed, branches. At least one post about disjoint timelines within a
>> project is here:
>> http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/14983
>>
>> I happen to use branches, just like you, and am fairly happy with
>> this. Nested repos were a bit overkill for me, but I guess that's
>> personal.
>>
>> Michai
>> ___
>> 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
>
___
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] Multiple Projects in one Repo

[Johan Kuuse]

Hi,

After some suggestions in this ML, I chose using nested repositories.
The "root repository", which I called 'nested', only contains a few files.
All other repositories are open inside the 'nested' directory, with the
-nested option.

Here is a script which clones, opens and updates the entire nested
directory tree (fossul-setuo.sh):

http://kuu.se/fossil/nested.cgi/doc/tip/index.html

Just my two cents to give you an idea...

BR,
Johan
El 12/9/2015 14:44, "Michai Ramakers"  escribió:

> Hello,
>
> On 12 September 2015 at 14:34, Oliver Friedrich
>  wrote:
> > I want to give a thought on how I use fossil regularly and on what I
> would
> > love as a feature.
> >
> > While fossil is easy to set up and maintain, I often have several small
> > projects that seem to be to small to get an own instance of a repository
> for
> > themselfes. Additionally, I like to use fossil, because it reduces the
> > number of files to manage (1 repo instead of dozens of files per
> project).
> >
> > That spoken, I have bunch of code-samples and abstracted code-problems in
> > different programming languages and flavours, that I keep as personal
> > knowledge database. I tend to give each of them its own fossil
> repository,
> > but as I mentioned before, sometimes they have just one or two files.
> >
> > My old solution was to have one repository with one set of folders for
> each
> > sub-project. But Timeline get messy really fast and it is hard to track
> > sub-projects with this approach.
> >
> > My current solution is to have one repository with an empty initial
> check-in
> > tagged as ROOT. Then I do one branch per sub-project based on the ROOT
> > check-in.
> >
> > That way I'm able to keep my code cleanly detached from each another,
> but it
> > feels really dirty - cause that's in no way the correct handling of
> > branches.
> >
> > What I really would like to have is to gather multiple such small
> projects
> > in one repo file, so instead of having one ROOT check-in, having one ROOT
> > for each project. I know that would make developing fossil a bit harder,
> but
> > I think it would be a great feature and that not I'm the only one who
> would
> > use this.
> >
> > In the simpliest logic I can imagine this would mean nothing more than
> one
> > additional layer, branches belong to project. For the normal use, each
> > branch would just belong to the default project. But I guess that
> > implementing this could be much harder, especially visualizations in the
> > web-frontend.
> >
> > But what do you think about multiple projects in one repo?
> > What would be your approach on my problem?
>
> I think this has come up a few times on this ML; I think some
> suggestions are to use nested repos ('fossil open --nested') or
> indeed, branches. At least one post about disjoint timelines within a
> project is here:
> http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/14983
>
> I happen to use branches, just like you, and am fairly happy with
> this. Nested repos were a bit overkill for me, but I guess that's
> personal.
>
> Michai
> ___
> 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

[fossil-users] Multiple Projects in one Repo

[Oliver Friedrich]

I want to give a thought on how I use fossil regularly and on what I would
love as a feature.

While fossil is easy to set up and maintain, I often have several small
projects that seem to be to small to get an own instance of a repository
for themselfes. Additionally, I like to use fossil, because it reduces the
number of files to manage (1 repo instead of dozens of files per project).

That spoken, I have bunch of code-samples and abstracted code-problems in
different programming languages and flavours, that I keep as personal
knowledge database. I tend to give each of them its own fossil repository,
but as I mentioned before, sometimes they have just one or two files.

My old solution was to have one repository with one set of folders for each
sub-project. But Timeline get messy really fast and it is hard to track
sub-projects with this approach.

My current solution is to have one repository with an empty initial
check-in tagged as ROOT. Then I do one branch per sub-project based on the
ROOT check-in.

That way I'm able to keep my code cleanly detached from each another, but
it feels really dirty - cause that's in no way the correct handling of
branches.

What I really would like to have is to gather multiple such small projects
in one repo file, so instead of having one ROOT check-in, having one ROOT
for each project. I know that would make developing fossil a bit harder,
but I think it would be a great feature and that not I'm the only one who
would use this.

In the simpliest logic I can imagine this would mean nothing more than one
additional layer, branches belong to project. For the normal use, each
branch would just belong to the default project. But I guess that
implementing this could be much harder, especially visualizations in the
web-frontend.

But what do you think about multiple projects in one repo?
What would be your approach on my problem?
___
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] Multiple Projects in one Repo

[Michai Ramakers]

Hello,

On 12 September 2015 at 14:34, Oliver Friedrich
 wrote:
> I want to give a thought on how I use fossil regularly and on what I would
> love as a feature.
>
> While fossil is easy to set up and maintain, I often have several small
> projects that seem to be to small to get an own instance of a repository for
> themselfes. Additionally, I like to use fossil, because it reduces the
> number of files to manage (1 repo instead of dozens of files per project).
>
> That spoken, I have bunch of code-samples and abstracted code-problems in
> different programming languages and flavours, that I keep as personal
> knowledge database. I tend to give each of them its own fossil repository,
> but as I mentioned before, sometimes they have just one or two files.
>
> My old solution was to have one repository with one set of folders for each
> sub-project. But Timeline get messy really fast and it is hard to track
> sub-projects with this approach.
>
> My current solution is to have one repository with an empty initial check-in
> tagged as ROOT. Then I do one branch per sub-project based on the ROOT
> check-in.
>
> That way I'm able to keep my code cleanly detached from each another, but it
> feels really dirty - cause that's in no way the correct handling of
> branches.
>
> What I really would like to have is to gather multiple such small projects
> in one repo file, so instead of having one ROOT check-in, having one ROOT
> for each project. I know that would make developing fossil a bit harder, but
> I think it would be a great feature and that not I'm the only one who would
> use this.
>
> In the simpliest logic I can imagine this would mean nothing more than one
> additional layer, branches belong to project. For the normal use, each
> branch would just belong to the default project. But I guess that
> implementing this could be much harder, especially visualizations in the
> web-frontend.
>
> But what do you think about multiple projects in one repo?
> What would be your approach on my problem?

I think this has come up a few times on this ML; I think some
suggestions are to use nested repos ('fossil open --nested') or
indeed, branches. At least one post about disjoint timelines within a
project is here:
http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/14983

I happen to use branches, just like you, and am fairly happy with
this. Nested repos were a bit overkill for me, but I guess that's
personal.

Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users