Development > Coding

Fossil

(1/2) > >>

Mike:
I wish this VCS was more popular. I like it more than git.

http://fossil-scm.org

sysdrum:
With git, working on two branches on the same project in different folders means I have two copies of the entire project history and branches in two distinct .git/objects directories that may be redundant and huge but something happens the chance of losing to many changes is less with Git. With Fossil the default working scheme is to have one single repository, and one or more working directories connected to it. So if screw the scheme you loss the whole scm. Maybe if disk usage is important single repo vs multi repo is important. But I like being able to see my path in the woods plus any forks along the way. 

Mike:
Hey sysdrum,

I guess I'm not quite understanding your rationale. Are you talking about a backup strategy or do you merge changes from separate repos at some point? If it's a backup strategy then why not rsync or cp your entire repo to another folder or drive? You could also use the fossil sync command to keep other repos up-to-date. Otherwise, you could just clone to your heart's content.

sysdrum:

--- Quote from: mlsmith on December 04, 2014, 07:06:18 AM ---Hey sysdrum,

I guess I'm not quite understanding your rationale. Are you talking about a backup strategy or do you merge changes from separate repos at some point? If it's a backup strategy then why not rsync or cp your entire repo to another folder or drive? You could also use the fossil sync command to keep other repos up-to-date. Otherwise, you could just clone to your heart's content.

--- End quote ---

Okay, so with Git if someone decides to make a major change I can fork the repo and they have the ability to work on the fork to say make a UI change that removes a slider and adds a new plugin option under the fork they have the ability to work side by side and if at some point the changes are stable they can be merged or the project can be spun off into something else or it can be a in place replacement without having to deal with cloned dependency hell. I also was just giving my opinion on why I prefer git. For some project a single scheme and repo SCM like fossil is way better than a multi scheme or fork-able multi repo like Git which is better for large multi dependent projects. Fossil is great for what it does and the ability to do inline backups on a single directory is nice. But it gets complicated when you need to do incremental backups and roll back changes if a merge goes south. Side note being able to host my own git lab for privite projects is also nice vs the way fossil does it. (but that in the end is a whole other topic) Also as I stated if you break the single SQLite3 database (but that is what backups are for) then you loss everything. I like fossil multiple peer checkouts from one repository at a time, which is very useful for myriad workflows. But it tends to limit side projects in the project that might take more time then the release schedule allows (so forking for a feature is nice with Git). I also like that with fossil it is an all in one stop shop. As fossil's APP includes multi-user access control, a web server, a wiki, a blog/news feed, and a ticketing system/issue tracker. But Git was meant to do one thing and one thing well and it does. Okay so I know this is super long. Fossil is great for what it does. Git is great for what it does.

Mike:
You make some great points and it's clear that you have more experience with both SCMs. I guess I haven't used Git enough in large scale projects to run into complicated scenarios as you mentioned. You're absolutely right about them both having unique strengths. Thank you for your opinion and knowledge. :)

Navigation

[0] Message Index

[#] Next page

Go to full version