3 ms·

> Then you're doing federated development, and you should continue to use Git or another tool that supports that style of development as a first-class activity.

> Then you're doing federated development, and you should continue to use Git or another tool that supports that style of development as a first-class activity. So, let's say I want to work on an open source project done in fossil. Let's say I don't personally know anyone associated with the project, and kind of just want to play around with it and I'm not even sure I'll be able to fix any bugs or add any useful features, or I just want to hack on an idea I had. How do I do this? Private branches? Isn't that what git offers? Sure, if there is never an expectation of an outsider looking at or hacking on the code, then a non-federated tool might make sense, but in any situation where the code is suppose to be public, I don't understand where the advantage is (or why I would ever voluntarily learn fossil unless as employer required it).

wyoung2 11y ago
> let's say I want to work on an open source project done in fossil....How do I do this? You clone the repo, open it into a working directory, and turn off autosync. Then all changes made to the repo affect only your local instance. If you think there's a chance that you might want to send your changes back upstream, you should probably work on a branch. Then when it comes time to send your changes to someone with checkin rights on the repo you cloned from, you can use a feature that is unique to Fossil, as far as I know, called bundles. (http://fossil-scm.org/xfer/help?cmd=bundle http://fossil-scm.org/xfer/help?cmd=bundle) It is essentially a slice of the Fossil repository that someone else can integrate into their own repo, not unlike a pull request on GitHub. I actually prefer to think of Fossil bundles as uber-patches, since they record not only the textual changes to the repo, but also file modes, the full checkin history, checkin comments, file removals and additions, etc. Basically, it fixes every weakness of patch(1). > I don't understand where the advantage is The advantages are listed on or linked from the front page of the Fossil web site: http://fossil-scm.org/ http://fossil-scm.org/ For me, the biggest single advantage is the simpler day-to-day working model, but maybe you will find another virtue that you prefer.

wyoung2 11y ago

> let's say I want to work on an open source project done in fossil....How do I do this? You clone the repo, open it into a working directory, and turn off autosync. Then all changes made to the repo affect only your local instance. If you think there's a chance that you might want to send your changes back upstream, you should probably work on a branch. Then when it comes time to send your changes to someone with checkin rights on the repo you cloned from, you can use a feature that is unique to Fossil, as far as I know, called bundles. (http://fossil-scm.org/xfer/help?cmd=bundle http://fossil-scm.org/xfer/help?cmd=bundle) It is essentially a slice of the Fossil repository that someone else can integrate into their own repo, not unlike a pull request on GitHub. I actually prefer to think of Fossil bundles as uber-patches, since they record not only the textual changes to the repo, but also file modes, the full checkin history, checkin comments, file removals and additions, etc. Basically, it fixes every weakness of patch(1). > I don't understand where the advantage is The advantages are listed on or linked from the front page of the Fossil web site: http://fossil-scm.org/ http://fossil-scm.org/ For me, the biggest single advantage is the simpler day-to-day working model, but maybe you will find another virtue that you prefer.