Live data from Hacker News

Why I Use Fossil

sheddingbikes.com

51–54 of 54 posts

Re: Why I Use Fossil

#51
post #44
post #23

Earlier quoted context omitted.

Forget rename detection ; it doesn't do renames period . So if you rename a file in one branch, you need to rename the file in the other branch BEFORE the merge, or you'll simply end up with two different files with different names.

Sigh, bullshit. I do this every day and it's just fine. You must be referring to some other concept of rename in some bizarrely complicated configuration you've worked yourself into.

I am referring to this sequence:

    gozer:~$ fossil new zed.fsl
    project-id: e4549d02538b1b58cf28488f76fc7549dc11a752
    server-id:  0bb5e1159eef42ed514c6ec13d17ba05f21ecdea
    admin-user: benjamin (initial password is "068bda")
    gozer:~$ mkdir zed
    gozer:~$ cd zed
    gozer:~/zed$ fossil open ../zed.fsl 
    gozer:~/zed$ echo hello > hello.txt
    gozer:~/zed$ fossil commit -m "initial"
    fossil: nothing has changed
    gozer:~/zed$ fossil add hello.txt 
    ADDED  hello.txt
    gozer:~/zed$ fossil commit -m "initial"
    New_Version: 10c3840dc611fdc22888571560b908f36e647e59
    gozer:~/zed$ echo zed >> hello.txt 
    gozer:~/zed$ fossil commit -m "edited"
    New_Version: 10aa55193ddd374a75d37508cbc8a09466a05019
    gozer:~/zed$ fossil update 10c384
    UPDATE hello.txt
    gozer:~/zed$ mv hello.txt hello2.txt
    gozer:~/zed$ fossil mv hello.txt hello2.txt
    RENAME hello.txt hello2.txt
    gozer:~/zed$ fossil commit -f -m "renamed"
    New_Version: 3c3253cbd31cbc479c888fb8b1f38a8a46d8d4d6
    **** warning: a fork has occurred *****
    gozer:~/zed$ fossil merge 10aa55
    gozer:~/zed$ ls
    _FOSSIL_       hello2.txt     manifest       manifest.uuid
    gozer:~/zed$ cat hello2.txt 
    hello
And just to go the other direction, since some DVCSes behave differently if their parents are in a different order:

    gozer:~/zed$ fossil update 10aa55
    ADD hello.txt
    REMOVE hello2.txt
    gozer:~/zed$ ls
    _FOSSIL_       hello.txt      manifest       manifest.uuid
    gozer:~/zed$ cat hello.txt 
    hello
    zed
    gozer:~/zed$ fossil merge 3c3253
    ADDED hello2.txt
    DELETE hello.txt
    gozer:~/zed$ cat hello2.txt 
    hello
Contrast this with Mercurial:

    gozer:~$ hg init zedhg
    gozer:~$ cd zedhg
    gozer:~/zedhg$ echo hello > hello.txt
    gozer:~/zedhg$ hg ci -Aminitial
    adding hello.txt
    gozer:~/zedhg$ echo zed >> hello.txt 
    gozer:~/zedhg$ hg ci -medited
    gozer:~/zedhg$ hg up 0
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
    gozer:~/zedhg$ hg mv hello.txt hello2.txt
    gozer:~/zedhg$ hg addremove -s100
    recording removal of hello.txt as rename to hello2.txt (100% similar)
    gozer:~/zedhg$ hg ci -mrenamed
    created new head
    gozer:~/zedhg$ hg merge
    merging hello2.txt and hell.txt to hello2.txt
    0 files updated, 1 files merged, 0 files removed, 0 files unresolved
    (branch merge, don't forget to commit)
    gozer:~/zedhg$ cat hello2.txt 
    hello
    zed
    
Git and Bazaar work similarly. This can come up very easily early in a product cycle--doubly so if you have the misfortune of working on a Java project where people are refactoring often.

Re: Why I Use Fossil

#52
post #41
post #24

While I love the idea of Fossil, I think Zed downplays a lot of the problems that it has in reality. There's no real way to throw out branches easily, nor is there any rebasing. Fossil doesn't track renames, so if you rename files in a branch, you'll need to rename them again on mainline before the merge. Fossil doesn't have any concept of patch management via email, which is fairly central to most OSS projects I'm i…

This is load of FUD and you know it. First, your claims are completely from your experience, like email patch management. Only a few projects use that, and most just tell you to put it in a Trac or similar. Second, all the things about "not being to see X" are configurable. But, then again I can't expect you to actually research a system before you go talking about it, 'cause that'd interfere with your FUD. Third, re…

I said that Fossil has no patch-based workflow. You say few projects use it.

I said that it can't rebase. You say that I shouldn't rebase.

I said that the bug tracker was hard to use because it's last-wins, not DAG based, which is a problem for a distributed bug tracker (Trac is not distributed, so it doesn't need to be DAG-based). You respond that Fossil has a bug tracker.

In all these cases, you don't refute my points. You're merely arguing they're immaterial. As such, your accusations of FUD and name-calling seem strange and defensive. You're welcome to contend that Fossil does not need these features, but since many projects and developers that I work with use them heavily, I think it'd make more sense to discuss why they are unnecessary or wrong.

Re: Why I Use Fossil

#53
I hadn't really heard of Fossil, so I went to read this post.

The one thing I really, really didn't give a damn about as I went to read a post like this was how everyone who doesn't like Fossil is merely a lazy, ignorant goon.

Whatever. I know bloggers like to gin up pointless arguments for the sake of controversy, but I don't give a shit about that sort of vapidity.

Re: Why I Use Fossil

#54
When I was evaluating Fossil about 1 year ago, compared to git and mercurial -- one of the requirements for my company was that it support large files. All of them supported large repositories, but easily ran into issues at about 10 MB for git and mercurial. Large file support for mercurial could be patched or extended but not in an ideal fashion. Fossil was able to handle files up to about 700 MBs in my tests before puking. I should add, those weren't binary files -- but large XML files.
Post reply on HN