4 ms·

> I may not own or be associated with the original repository? Then you're doing federated development, and you should continue to use Git or another tool that

by wyoung2 11y ago

> I may not own or be associated with the original repository? 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. Many years ago, I read that > 90% of all software development is in-house private stuff. (Billing systems, custom workflow management software, etc.) A big chunk of the rest is software for sale by a company. If you have federated development going on within the bounds of a single company, you've probably also got organizational silos, which is a problem. I suspect open source and SAAS have shifted that statistic in recent years, but I'd bet most software is still developed by a group of developers who all at least know each others' names, and can at least email each other, if not buttonhole each other at the water cooler. Other shifts in the market, such as from boxed software on retail shelves to app stores is a net zero in this discussion, since the software is still developed the same way. > It seems to come down to...centralized vs federated Yes. The popularity of Git has associated "DVCS" with federated development, but one of the points I'm trying to make is that you don't have to give up on the benefits of a centralized repository if you need a DVCS.

jimktrains2 11y ago
> 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.

by wyoung2 11y ago

jimktrains2 11y ago

> 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.