Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil SCM keeps more than just your code

blog.kotur.org

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Fossil SCM keeps more than just your code

#11

Post by panic »

thecatspaw wrote: post #2

In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Having Tickets, the Wiki and technotes in the same place is an interesting idea, but doesnt seem terribly valuable to me. It seems to violate the unix philosophy, as in it does more than is needed. I rather have a lightweight versioning control system, another lightw…

What happens if you accidentially add code where you dont own the copyright? Or an API Secret?

http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki

Re: Fossil SCM keeps more than just your code

#13

Post by jimktrains2 »

wereHamster wrote: post #6

> Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action leaves a trail, and you can not rewrite it. Ehm, That's not a fair assessment. Git is as much immutable as fossil. In fossils case, I can still poke around the sqlite database and delete rows from it. That may be difficult to pull of, because I expect the interna…

> Ehm, That's not a fair assessment. Git is as much immutable as fossil.

I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions).

What is the value in having history be static? I find that rebase comes in handy as I'm working locally, commit an absurd number of commits in stream-of-programming style, and then go back and clean it up before pushing to the shared repo. What is the analogous workflow in fossil?

Re: Fossil SCM keeps more than just your code

#14

Post by w_t_payne »

I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text.

For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or something richer.

To tie everything together, I maintain a diary, which consists of one text file per developer per sprint. This diary holds allocated jobs to do each sprint, together with a record of what was done each day.

Because all of my work information is available in the repository as text (markdown or YAML or JSON) - it means that I can automate my workflow in ways that would be much harder to achieve otherwise.

For example, I can extract appropriate git commit messages automatically from this diary, meaning that I have perfect traceability back to requirements on every commit. I can get my build to (optionally) commit changes automatically (rolling back if the build was not successful). I can even get it to (again optionally) make sure that all changes associated with a particular job are kept on a separate branch until that job is complete. In other words, I have lots of options when it comes to tying my workflow together with my CMS/VCS in an automated and scripted way.

And all because I am too lazy to open my web browser to look at JIRA or Trac (or whatever).

:-)

Re: Fossil SCM keeps more than just your code

#15

Post by w_t_payne »

w_t_payne wrote: post #14

I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text. For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or som…

It also means that -- because my "tickets" and "requirements" documents are just bits of YAML with a particular structure -- I can store tickets, requirements and so on pretty much anywhere in the repository - either in their own directories, or interspersed with and embedded within the source code as comments -- sort of like a TODO but with super-powers.

Re: Fossil SCM keeps more than just your code

#16

Post by koko775 »

jordigh wrote: post #3

This is a wonderful idea. The VCS, bug tracker, wiki, and web presence really should all be part of a packaged deal. Almost nobody uses just git -- they use github or gitlab. Very few people use Mercurial, because there is nowhere good to host it. Atlassian seems hell-bent on killing hg support off bitbucket, because few people use it, a very sad self-fulfilling prophesy. With offerings like gitlab, it might not make…

> Almost nobody uses just git -- they use github or gitlab.

Your points are made in a needlessly provocative manner.

Tons of people roll their own interfaces to their source control, and a lot of people benefit from somewhat centralized repositories. Not only is there room for both, but I don't see any data indicating how prevalent private, non-GitHub repositories are, or how those would even be counted accurately given the distributed model

Almost nobody? Very few people use Mercurial? Nowhere good? Hell-bent on killing? Few people use it? very sad self-fulfilling prophesy? Jeez, there's opinionated, then there's recklessly authoritative. Mercurial isn't as popular as git, but neither are dependent on GitHub/bitbucket for continued relevance.

To address your point more directly, I personally think that merging the concepts of versioned data and developer tasks makes for less flexibility; I prefer simple, pluggable, and modular to integrated when it comes to version control.

Re: Fossil SCM keeps more than just your code

#17

Post by crististm »

jordigh wrote: post #10
jimktrains2 wrote: post #8

Earlier quoted context omitted.

> Almost nobody uses just git -- they use github or gitlab. I don't understand what you mean. I know plenty of people that simply use SSH or local-only repositories. If you intend on sharing said repo, github is essentially cheap shared hosting (or did you also complain that people didn't run their own httpd?).

I know plenty of people that simply use SSH or local-only repositories. These people are the minority. Do you know at least 3 million people who use git without github? If not, you're nowhere near to saying that a majority of git users do not use github. And yes, having somewhere to host it is very important. Both Fossil and hg have an httpd built-in. I believe cgit or gitweb are not a simple "git serve" away?

We don't know how many people are using SSH git but you surely know they are much less than 3 million.

Have you heard about Dunning-Kruger effect?

Re: Fossil SCM keeps more than just your code

#18

Post by w_t_payne »

koko775 wrote: post #16
jordigh wrote: post #3

This is a wonderful idea. The VCS, bug tracker, wiki, and web presence really should all be part of a packaged deal. Almost nobody uses just git -- they use github or gitlab. Very few people use Mercurial, because there is nowhere good to host it. Atlassian seems hell-bent on killing hg support off bitbucket, because few people use it, a very sad self-fulfilling prophesy. With offerings like gitlab, it might not make…

> Almost nobody uses just git -- they use github or gitlab. Your points are made in a needlessly provocative manner. Tons of people roll their own interfaces to their source control, and a lot of people benefit from somewhat centralized repositories. Not only is there room for both, but I don't see any data indicating how prevalent private, non-GitHub repositories are, or how those would even be counted accurately gi…

The approach that I am taking is (at the moment) highly integrated -- and that is the thing that I am most concerned about -- I'd rather like to find a way to turn it into a set of disparate tools that use common (open) interfaces to work together -- But I haven't found a way to navigate towards that just yet.

Re: Fossil SCM keeps more than just your code

#20

Post by sgbeal »

ibmthrowaway271 wrote: post #5
thecatspaw wrote: post #2

In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Having Tickets, the Wiki and technotes in the same place is an interesting idea, but doesnt seem terribly valuable to me. It seems to violate the unix philosophy, as in it does more than is needed. I rather have a lightweight versioning control system, another lightw…

> In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history.

> Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history.

No, they won't. The fossil file format is very strongly protected against any changing of history. Changing history changes multiple hashes (at multiple levels) and breaks it. Immutable history is literally part of the metadata specification, and the db is "just a data store," independent of that specification.

Post reply on HN