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.
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
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
>
, 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 ad
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
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
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
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
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
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
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
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
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,
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
Hi,
I am creating multiple fossil repos. There is a way to share users and
passwords?
Because after the 4th repo, we would forget which user and password was
created on each repo
I was wondering how could reduce user management complexity
___
2011/3/3 Federico Ramallo frama...@gmail.com
Hi,
I am creating multiple fossil repos. There is a way to share users and
passwords?
Because after the 4th repo, we would forget which user and password was
created on each repo
I was wondering how could reduce user management complexity
On Thu, Mar 3, 2011 at 3:15 PM, Federico Ramallo frama...@gmail.com wrote:
Hi,
I am creating multiple fossil repos. There is a way to share users and
passwords?
Because after the 4th repo, we would forget which user and password was
created on each repo
I was wondering how could reduce
On Thu, Mar 3, 2011 at 3:21 PM, Richard Hipp d...@sqlite.org wrote:
On Thu, Mar 3, 2011 at 3:15 PM, Federico Ramallo frama...@gmail.com wrote:
I am creating multiple fossil repos. There is a way to share users and
passwords?
Fossil honors the REMOTE_USER cgi variable. So if you can configure
Actually I was thinking something like: john and mike work on project A and
B, C and so on ...
So far I created users on all projects.
Can I share the user table?
2011/3/3 Ron Wilson ronw.m...@gmail.com
On Thu, Mar 3, 2011 at 3:21 PM, Richard Hipp d...@sqlite.org wrote:
On Thu, Mar 3, 2011
On Thu, Mar 03, 2011 at 07:41:23PM -0600, Federico Ramallo wrote:
Actually I was thinking something like: john and mike work on project A and
B, C and so on ...
So far I created users on all projects.
Can I share the user table?
You can just copy the entries of the user table, yes.
Joerg
On Thu, Mar 3, 2011 at 8:43 PM, Joerg Sonnenberger
jo...@britannica.bec.dewrote:
On Thu, Mar 03, 2011 at 07:41:23PM -0600, Federico Ramallo wrote:
Actually I was thinking something like: john and mike work on project A
and
B, C and so on ...
So far I created users on all projects.
On March 3, 2011 12:15:39 PST, Federico Ramallo wrote:
Hi,
I am creating multiple fossil repos. There is a way to share users
and passwords?
Because after the 4th repo, we would forget which user and password
was created on each repo
I was wondering how could reduce user management
22 matches
Mail list logo