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,
On Tue, Jan 27, 2015 at 6:57 AM, Tony Papadimitriou to...@acm.org wrote:
* 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
- You cannot split out a project at a later time (wish list). So, you're
stuck with this arrangement for good.
Is the brand new bundle command a potential solution for this? I've only
read the docs so far, but it seems pretty powerful.
Jim
___
I personally think that fossil open --empty is a pretty good
strategy to keep multiple projects in the same repository.
Cheers.
- Vikrant
On 27 January 2015 at 03:57, Jim Kalafut j...@kalafut.net wrote:
I have a number of small, disparate projects that I'm moving into
Fossil. I've noticed
On Tue, Jan 27, 2015 at 8:57 AM, Tony Papadimitriou to...@acm.org wrote:
- You cannot split out a project at a later time (wish list). So, you're
stuck with this arrangement for good.
Actually, I think you sort of can. If you mark the roots of the projects
you do NOT want to clone as
On Tue, Jan 27, 2015 at 9:17 AM, Jim Kalafut j...@kalafut.net wrote:
- You cannot split out a project at a later time (wish list). So, you're
stuck with this arrangement for good.
Is the brand new bundle command a potential solution for this? I've only
read the docs so far, but it seems
6 matches
Mail list logo