Hi, >> 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. I'm afraid I simply don't understand. You set it up, it runs. You make backups using a cron script or the Task Scheduler. What more is there to administrating SVN? >> 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. You are confusing relationships between repositories, relationships between a working set and a repository, and branches.
What I described doesn't involve branches at all. When you clone A to B you have not branched anything. You have created a copy of the repository. That is all. The copy knows where it was copied from, so that it will automatically talk to the original repository when you try to push or pull. That alternative is that whenever you push or pull you must provide the path/URL of the other repository (which you don't need to do with git, hg, bazaar, fossil, etc. precisely because it makes this note that B is copied from A). Without making any changes to A or B, you can delete A, and then B will not be able to push/pull without you telling it where to find a new parent repository. You haven't lost any data from B. The full repository, including all of A (at the time of cloning or up to the last pull) is within B. But the tools that work on B don't know what to talk to when you try to push or pull, because they expected to talk to A and now A is missing. Branching cannot happen until you actually commit a change into a repository. So, if you did make changes on HEAD in B, and committed, and pushed, then either: (1) There have been no changes to HEAD on A since you cloned/pulled to B, in which case the changes are pushed into HEAD on A; OR (2) There have been changes to HEAD on A, and when sync'ing with B this creates a branch. In the numbered points about A is the default parent repository of B. Substitute A with any other repository if you tell B explicitly to push/pull/sync with another repository. >> 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. Hg and Bazaar use hard links. If you don't use hard links then you have to actually duplicate the file, which consumes time and space. Regards, Twylite _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
