Twylite wrote:
> Then use Visual SourceSafe, or Subversion. They are simple to
> understand: a network filesystem with an added dimension for time
> (revisions).
I googled for SourceSafe. Looks like it's a proprietary MS product. :(
I already know I don't want SVN. I had to admin it once, and I'll never
do it again.
> With any DVCS users must understand the distinction between a repository
> and a working set, and they must understand branching and merging.
You can use Darcs, Mercurial and Bazaar in a simple project without
having to go deeply into repository vs working set. And you only have to
deal with branching and merging if you actually have a team of users.
> Obtaining the files changes from "get" (or checkout or update, depending
> on your VCS) to "clone, open" or "pull, update". Committing a change
> changes from "commit" (or checkin) to "commit, push". The extra steps
> are not obvious to users who don't understand the DVCS paradigm, and can
> be very confusing ("I committed it, why can't he see it?" "Oh, you
> committed it but you didn't push it" "?!?").
I could be wrong, since I've been using DVCS for several years, but it
doesn't look complicated to me. I'd tell them that "commit" saves your
work and "push" uploads them to the server. But as I said, my
perspective might be affected by the fact that I already know these
concepts. Things always look easier when you already understand them.
> You also need to have all your projects in one repository, or one
> repository per project. Unlike a centralised VCS, partial (subtree)
> checkouts are not possible.
This isn't something users have to think about. I was planning to go for
one repository per project as an easy way to get access control and not
have people trampling on each other's work.
> So the former option just means extra
> traffic and storing for someone working on a single project; the latter
> means extra working if you need to sync and work on multiple projects.
No syncing. In my mind, if it's another project, it's unrelated.
> Furthermore the granularity of access control is at repository level
> (you either have access to the entire contents of a repository, or to no
> contents of the repository).
Yes. That's why I had in mind "one project, one repository".
> Since I'm not a beginner I can't comment on that ;p
>
> On the other hand I don't have a lot of patience. When I started with
> Fossil a few months back, it was after evaluating (read: install on my
> PC, play with, install on a server, play more) bazaar and hg. Fossil
> was significantly easier to use both locally and to get working on a
> server (I would use the word "trivial" for server installation, quite
> unlike bazaar/hg).
I have not tried to install bazaar or hg on the server. You might be
right. One of the things I was looking for with fossil is easier server
management. For example, I might think that Darcs is extremely easy to
use, but I'd have to give people SSH access to the server and I don't
want to deal with that can of worms. I was attracted by the idea of
using a CGI script, so I can give people access to *just* the SCM.
> When you clone A to B, a note is made in B that you cloned from A. So
> when you are working in B and you push or pull or sync it knows that the
> endpoint of that operation is A.
I think that's bad. Darcs doesn't do that, and I would venture to guess
that Bazaar and Mercurial don't either. Branches should be equal and
independent.
> That sequence applies to Fossil, Git, Hg, Bazaar, and DVCS in general.
I can't comment about Git. I don't think this is true for Hg or Bazaar.
I can guarantee it is not true for Darcs. As I said, branches should be
equal and independent. Inter-branch dependencies seems like the opposite
of decentralization.
> It also leads to some WTF behaviour. For example, you make a change to
> A, commit, push. Then you make a change to B, commit, push. Then you
> delete both A and B because you've finished and pushed the changes.
Indeed. If my SCM did that I'd be furious.
> Did you notice that you lost the changes you made in B? Because you
> pushed them to A, not to REMOTE? That happens a lot with new users of
> git, bazaar and hg, because each working set on your PC has an attached
> repository. With Fossil there is one local repository with multiple
> local working sets, so you don't have this problem.
I have *never* heard of something like this happening. Maybe I'm too
stuck with Darcs, but I'm a bit shocked to hear that Hg or Bazaar have
inter-branch dependencies like you suggest. I think I might go to the Hg
or Bazaar mailing list and verify this. It doesn't sound right at all.
>>> Fossil keeps the concept of the repository and the working set distinct.
>> Btw, AFAIK the only SCM that joins these concepts is Darcs.
> Wrong. Git, Hg and (depending on your workflow) Bazaar all keep a
> repository clone local to the working set.
In the same directory, but pulling from another branch doesn't force you
to put all the changes in your working directory. There's an important
distinction there. I can sync my repository with you, but not apply your
changes to my working tree. Or I can apply some of your changes but not
others.
> Then they muck with
> hardlinks and copy-on-write to try and conserve disk space and improve
> performance. (You don't want to use these on a FAT32 filesystem)
Some muck with hard links, others don't. AFAIK it is Hg that uses hard
links.
Daniel.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
