Hot answers tagged

24

Personally, I update my local versions daily. In the scenario you describe, I would go the extra mile by Creating a branch for the new, lengthy feature. Merge often from the mainline to this new branch. This way, You can check-in daily to preserve your code on the server You don't have to worry about breaking the build by checking-in. You can use the ...


15

I don't claim to be an expert on the subject of hype cycles, but I'll offer a few observations: The hype cycle seems to be more a product of expectations and media coverage than a characteristic of technology itself. My dictionary says that hype is "extravagant or intensive publicity or promotion." It defines publicity as "the notice or attention given to ...


12

I do Mercurial consulting and my experience is that big companies spend a lot of time up-front to investigate the pros and cons of DVCS. So when they finally take the jump, they've already been using DVCS for one or two pilot projects and so they're pretty certain that it will work for the rest of the group. However, I do know of one example where Mercurial ...


6

I would advise against it. Database schemata change together with other related code or resources. To be able to track changes properly, you need to make cohesive changes link to each other, and a shared commit is the best way to go about it. Consider your suggestion of keeping the schema under a separate branch. First off, you keep branches so you can push ...


6

It's not terribly difficult to set up a pull request flow on a CVCS, it's just that no one does because they don't want to manage a gazillion personal branches on the server. Perforce is one of the rare CVCS vendors trying to address this by introducing features like streams and sandbox. There is one way DVCS distinguishes itself. It gives you more ...


6

Yes, it is a good idea to update often. You update often to avoid difficult merge conflicts and this is the basics of Software Configuration Management (SCM) knowledge with the problem of divergent changes. This is regardless if it is centralized or distributed; the longer time you diverge from an upstream source (meaning if it is a trunk, branch, or other ...


5

The hype cycle measures the amount of news/buzz that a particular thing generates, not the actual use of the thing or it's actual productivity value. So... I would say that from that perspective, DVCS is reaching a spike in its news cycle. Enough people are actually using it and encouraging other people to use it that it is getting a lot of buzz in the tech ...


4

In addition to the indirect better tools allowing programmers to do better job, there are some cases where there may be more direct effect. If you are developing for another company and for any reason it's not possible to access intranet of one from the other, than any time you need to debug and fix something at customer site having working version control ...


4

Absolutely. A programmer who uses the best available tools will create a better end result. A DVCS is a very good tool with very real benefits. Comparing DVCS to no source control at all is like comparing paint to mud. A painter who uses high quality paint on the walls of your house will do a much better job than a painter who uses mud. Comparing DVCS to ...


4

The two aren't exclusive alternatives. CVCS tools provides strong authorization features. Some have their own built-in authentication mechanism (SVN with svnserve, RTC and its user registry, Perforce and its P4Admin): they can have their own internal user database, dedicated for their tools. DVCS tools don't. See "Can we finally move to DVCS in Corporate ...


4

The 3rd bullet point in the question is simply wrong: You are working on a new feature which will surely take several days to complete, and you won't be able to commit before that because it would break the build. If you know you are going to be working on something you cannot commit for some time, that is the textbook example for using ...


3

Everyone here seems to agree that projects using DVCS have shorter release cycles over all, but it's still not certain that the adoption of a DVCS causes the shorter cycles: Correlation is not causation! Distributed VCS and short release cycles are both relatively new technologies. Projects that embrace one are likely to embrace the other, while groups ...


3

What makes software release cycle shorter with DVCS, compared to CVCS? I don't think there is necessarily a difference between DVCS and CVCS here, but rather a difference in the branching model that people adhere to. From what I have gathered here and from my experience, people using DVCS tend to use more branches than people using CVCS. And if you develop ...


2

argument/evidence of a particular phase Whatever phase could that be, it has to be one that matches the fact that technology is in professional use for "more than 10 years", since distributed VCS TeamWare has been there for more than that: pdf User's Guide referred below is dated July 2001. Per Wikipedia, TeamWare's largest deployment was inside Sun itself,...


2

I think you should commit more often. If you are going to work for a long time like few days, you should branch your code and work in your branch rather than working directly in the trunk. I know it's convenient to start working without branches, but it's not really flexible as you cannot be sure that your update/commit would break your code or not, which ...


2

Good question! The CVCS believe in the primary principle that everything must keep merging/syncing back to 'the trunk'. Also, we expect that as we evolve, trunk should be the most stable points before release is made. So people put their work in working copy, take update and test before check-in. Or alternatively, you work on private/feature branches and ...


1

What makes software release cycle shorter with DVCS, compared to CVCS? I agree with Bart that the primary reason is the branching model used, but the type of version control system directly affects which branching models are viable. So we have two sub-questions. What branching model the distributed systems support better and why it makes release cycle ...


1

I'd recommend to put all kinds of sourcecode together that builds up a running system (inlcuding database-queries and -schemas) Why? Because, then you always have a relation between your code and the rest of the things that build your system (configuration, SQL, Readmes, Tests, ...). If you make a change, you get certainly reminded to change those other ...


1

I actually find it more convenient to use a distributed version control locally. That is, I use git as subversion client. This has the advantages that: The local changes are saved before updating, so if I make mistake in the merge, I can always go back and do it again. When doing bigger changes, I can save the parts that are finished. That makes it easier ...


1

My Answer: I think that the answer lies somewhere between "Internet TV" and "Cloud Computing" on the rising shoulder of the "Peak of Inflated Expectations" (Although I think that both of these have moved on somewhat rapidly in the past couple of years). Nature of the Hype Cycle: As I understand it, progression through the hype cycle is characterized by an ...


Only top voted, non community-wiki answers of a minimum length are eligible