dvcs

The rebaseif mercurial extension automates the process, when pulling, of doing a rebase only if the merge can be done automatically with no conflicts. (If there are conflicts to resolve manually, it does not rebase, leaving you ready to do a manual merge of the two branches.) This simplifies and linearizes the history when developers are working in different parts of the code, although any rebase does throw away some information about the state of the world when a developer was doing work. I tend to agree with arguments like this and this that in the general case, rebasing is not a good idea,

We want to use Git to deploy code on our webserver. Therefore, we have a initialized a bare repository on our production server. Whenever we release a new version, we perform a git checkout into the DocumentRoot of the website: git --work-tree=/path/to/webroot/ checkout -f master In the subdirectories of webroot , there are several files which are not tracked by Git (Cache files, user-uploaded files etc.). These must of course not be deleted by Git when performing the checkout (and this part works fine so far). However, Git also does not delete files which were previously tracked, but have

BRIEF: I want to have two (or more) "streams of development" / environments track each other, sending changes between each other in both directions, without converging totally - while preserving certain key, essential, differences? DETAIL, ONE PARTICULAR EXAMPLE: Here is one particular example: I have been version controlling my home directory, glew-home, for, oh, 28 years. RCS, SCCS, many RCS wrappers, CVS, SVN, a brief period of experimentation with early DVCS like Monotone and Darcs, bzr, git, and now Mercurial. At the moment I am mainly happy using Mercurial, although I'll jump back to git

I've one question about general DVCS, including Git and Hg. In both Git and Hg merge tracking is done at the "commit" level instead of the "file/directory" level. One of the "side effects" is that you can't easily do a "partial merge": You've modified 30 files in your branch "feature_branch_x" You want to merge ONLY the files under (let's say) /kernel/gui With "item based merge tracking" (Perforce, ClearCase, Plastic SCM <= 3.0) you can just select a few files to merge, then checkin, then later repeat the merge and the pending files will show up. With Hg, Git: once you merge (there're ways to

What would be the best approach for versioning my whole database ? Creating a file for each database object (table,view,procedsure..) or rather having one file for all DDL scripts and any new change will be put in a separate file ? What about handling changes made in a Database manager tool ? I'd like to have a generic solutions for any kind of RDBMS. Are there any other options ? I'm a huge VCS fan in general and a big Mercurial booster, but I really think you're going down the wrong path. VCSs aren't just about iterative changes, the "what", they're also about answering the "who", "when",

We are doing development for automation code. Our code automates the company's products and is synced to a particular product version. Currently, we have 1 big Git repository with multiple branches in it - v1.0, v1.1, v2.0 (automation for version 1.0 goes in v1.0 branch, and so on). What are the advantages and disadvantages of having these in a single repository with branches vs. keeping each version code in a separate repository ? Both solutions can work, the answer i'm looking for is a list of pros/cons for either approach. I know that many teams are using branches to isolate temporary