dvcs

I have two related repositories, a master, which contains a number of sensitive files which must not be leaked, and a 'public' version, created with hg convert with --filemap to exclude the sensitive files and directories. I would like further updates to the master that don't affect the sensitive files to be pushable to the slave, and updates to the slave to be pullable by the master. Right now this doesn't happen, as they are considered 'unrelated' repositories If this is possible with Git, but not with Mercurial, migration is a possibility, though it will be a nuisance since some development

I just started to use Mercurial and I think I'm trying to do something very simple, something that should be quite typical, but I'm stumped on why it's so complicated, and why it doesn't just work the way it should (IMO). I share some a repository with a friend, he makes some changes and checks in several files and pushes them. Now in svn I'm used to just updating my working copy and getting his changes, no hassle. But with mercurial apparently I have to merge. What I don't get is: shouldn't mercurial be smart enough to figure out that if my friend made the most recent changes, and I haven't

Is there an easy way to find the SHA1 of the first commit in a project with a long history with git? Just off the top of my HEAD, this should get one of the 'first' commits of the current branch. git rev-list --reverse HEAD | head -1 (If the branch contiains two unrelated branches which have been merged together, it's not guaranteed which root you will get but you could use --date-order to select the oldest.) git log --reverse | head -n1 来源： https://stackoverflow.com/questions/3270696/checking-out-a-projects-first-commit-with-git

As I getting acquainted with Git, I feel more and more that: Git and other DVCS jump a step futher than traditional centralized VCS in that they not only check out files in question, but also the whole version database. I think this is the major difference between DVCS and CVCS, and also the major foothold of all other benefits of DVCS. Or, let's put it this way: Multiple Local VCS + A Centralized Backup = DVCS. Changed the above equation to this: Multiple Local Clones + A Centralized Backup = DVCS. Right? VonC What you are describing is the very nature of a distributed system: the whole

When working on multiple (open source) projects, multiple version controll systems start to be problematic. While they share common operations, I often make mistakes by typing hg add instead git add . I remember seeing project some time ago that made access to different source control software in uniform way by providing basic commands commit/ci add etc. in shell. Depending on repository it would in turn call hg add or git add etc. I've seen Amp: http://amp.carboni.ca/ (which seems to be down ATM) any other scripts like that? Johannes Rudolph I think unifications of two (in this case