You are Here:
Linux Lite 4.6 Final has been released. See the Release Announcements section for more information.



Fossil

Author (Read 6533 times)

0 Members and 1 Guest are viewing this topic.

Fossil
« on: December 03, 2014, 08:35:09 PM »
 

Mike

  • Forum Regular
  • ***
  • 212
    Posts
  • Country: us
  • Reputation: 26
  • Linux Lite Enthusiast

  • Linux Lite: 3.6 64bit
I wish this VCS was more popular. I like it more than git.

http://fossil-scm.org
 


Re: Fossil
« Reply #1 on: December 03, 2014, 09:40:27 PM »
 

sysdrum

  • Saying the wrong things at the right time.
  • Occasional Poster
  • **
  • 83
    Posts
  • Country: us
  • Reputation: 12
  • That's personal.

  • Linux Lite: 3.8 64bit

  • CPU: Intel Core i5-6400

  • MEMORY: 16Gb

  • VIDEO CARD: Nvidia 1050 Ti
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. 
 

Re: Fossil
« Reply #2 on: December 04, 2014, 07:06:18 AM »
 

Mike

  • Forum Regular
  • ***
  • 212
    Posts
  • Country: us
  • Reputation: 26
  • Linux Lite Enthusiast

  • Linux Lite: 3.6 64bit
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.
 

Re: Fossil
« Reply #3 on: December 04, 2014, 10:52:54 AM »
 

sysdrum

  • Saying the wrong things at the right time.
  • Occasional Poster
  • **
  • 83
    Posts
  • Country: us
  • Reputation: 12
  • That's personal.

  • Linux Lite: 3.8 64bit

  • CPU: Intel Core i5-6400

  • MEMORY: 16Gb

  • VIDEO CARD: Nvidia 1050 Ti
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.

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.
 

Re: Fossil
« Reply #4 on: December 04, 2014, 07:34:46 PM »
 

Mike

  • Forum Regular
  • ***
  • 212
    Posts
  • Country: us
  • Reputation: 26
  • Linux Lite Enthusiast

  • Linux Lite: 3.6 64bit
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. :)
 

Re: Fossil
« Reply #5 on: December 09, 2014, 02:54:04 AM »
 

N4RPS

  • Donator
  • Platinum Level Poster
  • **********
  • 1151
    Posts
  • Country: us
  • Reputation: 154
  • Knows JUST ENOUGH Linux to be DANGEROUS
    • Orphans for Christ, Self Advocates of Mecklenburg

  • Linux Lite: 2.6 64bit

  • CPU: Several Different 32-bit & 64-bit CPUs, 2-8 GB RAM

  • MEMORY: 8Gb

  • VIDEO CARD: Several Different AMD and Intel GPUs
Hello!

Thanks for the discussion. One never knows exactly how many others will benefit from it!

73 DE N4RPS
Rob


A gun in your hand is worth more than a whole police force on the phone.
 

Re: Fossil
« Reply #6 on: December 09, 2014, 06:47:10 AM »
 

Mike

  • Forum Regular
  • ***
  • 212
    Posts
  • Country: us
  • Reputation: 26
  • Linux Lite Enthusiast

  • Linux Lite: 3.6 64bit
Very true. I suspect Fossil could be helpful for smaller teams to coordinate and document their project in one spot.
 


Tags:
 


Linux Lite 4.6 Final has been released. See the Release Announcements section for more information.