Search Results

Search found 179 results on 8 pages for 'dvcs'.

Page 1/8 | 1 2 3 4 5 6 7 8  | Next Page >

• dvcs - is "clone to branch" a common workflow?

  - by Tesserex

  I was recently discussing dvcs with a coworker, because our office is beginning to consider switching from TFS (we're a MS shop). In the process, I got very confused because he said that although he uses Mercurial, he hadn't heard of a "branch" or "checkout" command, and these terms were unfamiliar to him. After wondering how it was possible that he didn't know about them and explaining how dvcs branches work "in place" on your local files, he was quite confused. He explained that, similar to how TFS works, when he wants to create a "branch" he does it by cloning, so he has an entire copy of his repo. This seemed really strange to me, but the benefit, which I have to concede, is that you can look at or work on two branches simultaneously because the files are separate. In searching this site to see if this has been asked before I saw a comment that many online resources promote this "clone to branch" methodology, to the poster's dismay. Is this actually common in the dvcs community? And what are some of the pros and cons of going this way? I would never do it since I have no need to see multiple branches at once, switching is fast, and I don't need all the clones filling up my disk.

  Read the article

• What GUI tools are available for which DVCS?

  - by Macneil

  When I worked at Sun, we used a DVC system called Forte SCCS/Teamware, which used the old SCCS file format, but was a true distributed source code revision control system. One nice feature is that it had strong GUI support: You could bringover and putback changes by simply clicking and dragging. It would draw trees/graphs showing how workspaces relate to each other. You also could have a graph view to display a single file's complete history, which might have had several branches and merges. Allowing you to compare any two points. It also had a strong visual merge tool, to let you accept changes from one of two conflicting files. Naturally, many of the current DVCSs have command line support for these operations, but I'm looking for GUI support in order to use this in a lower-level undergraduate course I'll be teaching. I'm not saying the Forte Teamware solution was perfect, but it did seem to be ahead of the curve. Unfortunately, it's not a viable option to use for my class. Question: What support do the current DVCSs have with regards to GUIs? Do any of them work on Windows, and not just Linux? Are they "ready for prime-time" or still works in progress? Are these standalone or built as plug-ins, e.g., for Eclipse? Note: To help keep this discussion focused I'm only interested in GUI tools. And not a meta-discussion if GUI tools should be used in teaching.

  Read the article

• Are there advantages to using a DVCS for a solo developer?

  - by SnOrfus

  Right now, I use visual svn on my server, and have ankhsvn/tortoise on my personal machine. It works fine enough, and I don't have to change, but if I can see some benefits of using a DVCS, then I might give it a go. However, if there's no point or difference using it without other people, then I won't bother. So again, I ask, are there any benefits to using a DVCS when you're the only developer?

  Read the article

• How to Make a DVCS Completely Interoperable with Subversion?

  - by David M

  What architectural changes would a DVCS need to be completely interoperable with Subversion? Many DVCSs have some kind of bidirectional interface with Subversion, but there are limitations and caveats. For instance, git-svn can create a repository that mirrors Subversion, and changes to that repo can be sent back to Subversion via 'dcommit'. But the git-svn manpage explicitly cautions against making clones of that repository, so essentially, it's a Subversion working copy that you can use git commands on. Bazaar has a bidirectional Subversion capability too, but its documentation notes that Subversion properties aren't supported at all. Here's the end that I'm pursuing. I want a Subversion repository and a DVCS repository that, in the steady state, have identical content. When something is changed on one, it's automatically mirrored to the other. Subversion users interact with the Subversion repository normally. DVCS users clone the DVCS repository, pull changes from it, and push changes back to it. Most importantly, they don't need to know that this special DVCS repository is associated with a Subversion repository. It would probably be nifty if any clone of the special repository is itself a special repository and could commit directly to Subversion, but it might be sufficient if only the special repository directly interacts with Subversion. I think that's what mostly needed is to improve the bidirectional capability so that changes to Subversion properties are translated to changes in the DVCS repository. Some changes in the DVCS repository would be translated to changes to Subversion properties. Or is the answer to create a new capability in Subversion that interacts with a DVCS repository, using the DVCS repository as just a special storage layer such as fsfs or bdb? If there's not a direct mapping between the things that Subversion and a DVCS regard as having versions, does that imply that there's always going to be some activity that cannot be recorded properly on one or the other?

  Read the article

• DVCS and data loss?

  - by David Wolever

  After almost two years of using DVCS, it seems that one inherent "flaw" is accidental data loss: I have lost code which isn't pushed, and I know other people who have as well. I can see a few reasons for this: off-site data duplication (ie, "commits have to go to a remote host") is not built in, the repository lives in the same directory as the code and the notion of "hack 'till you've got something to release" is prevalent... But that's beside the point. I'm curious to know: have you experienced DVCS-related data loss? Or have you been using DVCS without trouble? And, related, apart from "remember to push often", is there anything which can be done to minimize the risk?

  Read the article

• Push DVCS repository to master without needing codebase

  - by Scorchin

  To work on a client's staging environment I have to connect through a VPN which locks all normal network traffic and prevents any connection to the Internet. This would immediately prevent any of the "normal" VCS solutions from being used as it's not possible to gain access to the server. A solution to this would be to create a DVCS repository (git?) locally and then push changes to the master, as and when needed. There is one flaw in this plan. The entire codebase is around 14GB. To download all of this over the internet would take some time, especially when I'm likely to be working on 3 or 4 different machines in each case. This seems silly and overkill for a DVCS. TL;DR Can any DVCS solution allow you to push to a master server/repo without needing the codebase? Bad example: copy the .git folder (not the 14GB codebase) to another directory and push this to the master once disconnected from the VPN.

  Read the article

• I'm a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS?

  - by user2567

  I try to understand the benefits of distributed version control system (DVCS). I found Subversion Re-education and this article by Martin Fowler very useful. Mercurial and others DVCS promote a new way of working on code with changesets and local commits. It prevents from merging hell and other collaboration issues We are not affected by this as I practice continuous integration and working alone in a private branch is not an option, unless we are experimenting. We use a branch for every major version, in which we fix bugs merged from the trunk. Mercurial allows you to have lieutenants I understand this can be useful for very large projects like Linux, but I don't see the value in small and highly collaborative teams (5 to 7 people). Mercurial is faster, takes less disk space and full local copy allows faster logs & diffs operations. I'm not concerned by this either, as I didn't notice speed or space problems with SVN even with very large projects I'm working on. I'm seeking for your personal experiences and/or opinions from former SVN geeks. Especially regarding the changesets concept and overall performance boost you measured. UPDATE (12th Jan): I'm now convinced that it worth a try. UPDATE (12th Jun): I kissed Mercurial and I liked it. The taste of his cherry local commits. I kissed Mercurial just to try it. I hope my SVN Server don't mind it. It felt so wrong. It felt so right. Don't mean I'm in love tonight. FINAL UPDATE (29th Jul): I had the privilege to review Eric Sink's next book called Version Control by Example. He finished to convince me. I'll go for Mercurial.

  Read the article

• What is the difference between DVCS systems?

  - by Stephen

  What is the difference between DVCS systems? Seriously, wikipedia doesn't cover it well, and I read an article on HN recently comparing git and bzr in some detail, but the author admitted knowing little about mercurial, and the other options didn't get mentioned. (I'm happily using fossil on small win/mac/Linux projects) Please restrict answers to the DVCS aspects of the tool, e.g. The basic unit of vc in hit is the repository- in bazaar it is the branch(http://unspecified.wordpress.com/2010/03/26/why-git-aint-better-than-x/). bugtrackers and wikis are nice, but I'm really interested in the tools themselves, rather than any extras. Unfortunately SO demands a single 'right answer', so I'm making the question community wiki in the hope that users will contribute their knowledge.

  Read the article

• Are there open source alternatives to Bitbucket, Github, Kiln, and similar DVCS browsing and management tools?

  - by Ryan Taylor

  I am aware of several tools/services that provide DVCS browsing and management such as Bitbucket, Github, Kiln, SCM-Manager and Rhodecode. However, the use case I am considering is one such that: Any source code must reside on an employers internal servers. The solution must be open source. It should provide a Bitbucket or Github like experience, including a project wiki, repository browsing and management, and social coding aspects such as code review. The solution should have mercurial support (if not support for other DVCSs). Of these, only SCM-Manager and RhodeCode come close as they can be installed on your own servers and are open source. However they do not have the Bitbucket or Github experience. There is no issue tracker or wiki and the UI, while functional, is not up to par with Github or Bitbucket. I can get close with Trac or Redmine with their repository browsers but unfortunately they do not have any repository management capabilities. Are there other open source tools out there that would provide a similar experience to Bitbucket, Github or Kiln?

  Read the article

• Which DVCS is most conducive to experimenting?

  - by dasickis

  I was wondering which DVCS is most conducive to experimentation i.e. branching, etc. I want something where anyone can quickly launch smaller projects and refactor code quickly. I want to create an environment where experimenting is cheap and can be discarded/merged easily.

  Read the article

• Describe your workflow of using version control (VCS or DVCS)

  - by edwin.nathaniel

  I'd like to learn other people workflow when using either SVN or GIT. Please describe your strategy to handle the following tasks: Implement a feature Fixing bugs (during development and deployed app) Code Review Refactoring code (post code-review) Incorporate patches Releasing the newer version of your app (desktop, web, mobile, would you treat them differently?) Feel free to organize your answer not grouped by the tasks but grouped by whatever you think is relevant but please organize it by VCS/DVCS (please don't mix them). Thank you.

  Read the article

• Combine DVCS with Visual Source Safe

  - by WBlasko

  I'm forced to use Visual Source Safe 2005 at work. I'd like to combine that with a DVCS, so that I can check in files locally without disrupting my co-workers if there's a bug or it doesn't compile. In my attempts with Mercurial, it works, but causes a few weird issues. Namely, it thinks someone else has checked out the files I have checked out. Here's my thoughts on how I should manage it: Disable auto-checkout. Work locally in Mercurial When I'm ready to push my changes... Clone my Mercurial repository. Update my Visual Source Safe repository Pull and merge the two repositories using Mercurial. Check everything into Visual Source Safe. Does this sound reasonable? I'm always hearing bad things about VSS, is this just asking for me to see those problems firsthand?

  Read the article

• What DVCS support Unicode filenames?

  - by Craig McQueen

  I'm interested in trying out distributed version control systems. git sounds promising, but I saw a note somewhere for the Windows port of git that says "don't use non-ASCII filenames". I can't find that now, but there is this link. It's put me off git for now, but I don't know if the other options are any better. Support for non-ASCII filenames is essential for my Japanese company. I'm looking for one that internally stores filenames as Unicode, not a platform-dependent encoding which would cause endless grief. So: What DVCS support Unicode filenames? In both Windows and Linux? Ideally, with the possibility to transfer repositories between Windows and Linux machines with minimal issues?

  Read the article

• What makes merging in DVCS easy?

  - by afriza

  I read at Joel on Software: With distributed version control, the distributed part is actually not the most interesting part. The interesting part is that these systems think in terms of changes, not in terms of versions. and at HgInit: When we have to merge, Subversion tries to look at both revisions—my modified code, and your modified code—and it tries to guess how to smash them together in one big unholy mess. It usually fails, producing pages and pages of “merge conflicts” that aren’t really conflicts, simply places where Subversion failed to figure out what we did. By contrast, while we were working separately in Mercurial, Mercurial was busy keeping a series of changesets. And so, when we want to merge our code together, Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together. By looking at the SVN's repository folder, I have the impression that Subversion is maintaining each revisions as changeset. And from what I know, Hg is using both changeset and snapshot while Git is purely using snapshot to store the data. If my assumption is correct, then there must be other ways that make merging in DVCS easy. What are those?

  Read the article

• Is IDE integration *really* useful for a DVCS?

  - by Jerry Rubin

  Specifically, for Visual Studio 2008 (or 2010) and Mercurial, but generalize if desired.

  Read the article

• Is this a good centralized DVCS workflow?

  - by Chad Johnson

  I'm leaning toward using Mercurial, coming from Subversion, and I'd like to maintain a centralized workflow like I had with Subversion. Here is what I am thinking: stable (clone on server) default (branch) development (clone on server) default (branch) bugs (branch) developer1 (clone on local machine) developer2 (clone on local machine) developer3 (clone on local machine) feature1 (branch) developer3 (clone on local machine) feature2 (branch) developer1 (clone on local machine) developer2 (clone on local machine) As far as branches vs. clones is concerned, does this workflow sense? Do I have things straight? Also, the 'stable' clone IS the release. Does it make sense for the 'default' branch to be the release and what all other branches are ultimately merged into?

  Read the article

• eclipse+bzr (Or: DVCS + IDE)

  - by Adam Matan

  Hi, I have some projects on bzr code repositories shared with colleagues. Problem is, I really want to switch to eclipse in some projects, but I don't want to pollute the repository with the unnecessary metadata eclipse creates in its Workspaces. Any idea how to keep Eclipse's metadata outside my bzr repo? Adam

  Read the article

• DVCS - What's the downside of rewriting unpublished history?

  - by user1447278

  I was wondering what in particular is the downside of "losing history" in a development process. One famous example is of course git rebase -i / git merge --squash, but also what is described here: http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar under "I want to clean up my commit history prior to submitting my changes to the mainline." I can see that exporting patches and applying them to another branch would lose the "history" of the branch, but why would that branch and its commit history be useful after it has been merged? Can someone elaborate on why such techniques are considered "dirty"? Why does it matter in which order changes were originally committed in the first place as long as they can be applied to the main branch?

  Read the article

• Does it make sense to commit after every save with a DVCS?

  - by blockhead

  I know the question has been asked before how often to commit with a DVCS. All answers have one thing in common--as often as possible. But they're usually something like, after finishing a thought, a user story, getting code that compiles, or passing tests. I was thinking, given that a DVCS gives you you're own repository, with very cheap commits, doesn't it make sense, to commit after every change to a file? After all, this is what happens in NetBeans, and you get a nice free "time machine" without even asking for it. If not every change, then at least every save, or compile. Does this make sense, or do I have the wrong idea about DVCS. My feeling is that this not the workflow most people have with DVCS.

  Read the article

• Headaches using distributed version control for traditional teams?

  - by J Cooper

  Though I use and like DVCS for my personal projects, and can totally see how it makes managing contributions to your project from others easier (e.g. your typical Github scenario), it seems like for a "traditional" team there could be some problems over the centralized approach employed by solutions like TFS, Perforce, etc. (By "traditional" I mean a team of developers in an office working on one project that no one person "owns", with potentially everyone touching the same code.) A couple of these problems I've foreseen on my own, but please chime in with other considerations. In a traditional system, when you try to check your change in to the server, if someone else has previously checked in a conflicting change then you are forced to merge before you can check yours in. In the DVCS model, each developer checks in their changes locally and at some point pushes to some other repo. That repo then has a branch of that file that 2 people changed. It seems that now someone must be put in charge of dealing with that situation. A designated person on the team might not have sufficient knowledge of the entire codebase to be able to handle merging all conflicts. So now an extra step has been added where someone has to approach one of those developers, tell him to pull and do the merge and then push again (or you have to build an infrastructure that automates that task). Furthermore, since DVCS tends to make working locally so convenient, it is probable that developers could accumulate a few changes in their local repos before pushing, making such conflicts more common and more complicated. Obviously if everyone on the team only works on different areas of the code, this isn't an issue. But I'm curious about the case where everyone is working on the same code. It seems like the centralized model forces conflicts to be dealt with quickly and frequently, minimizing the need to do large, painful merges or have anyone "police" the main repo. So for those of you who do use a DVCS with your team in your office, how do you handle such cases? Do you find your daily (or more likely, weekly) workflow affected negatively? Are there any other considerations I should be aware of before recommending a DVCS at my workplace?

  Read the article

• Where could Distributed Version Control Systems currently be in Gartner's hype cycle?

  - by dukeofgaming

  Edit: Given the recent downvoting (+8/-6 at this point) it was made clear to me that Gartner's lifecycle is a biased metric from a programmer's perspective. This is something that is part of a paper I'm going to present to management, and management types are part of Gartner's audience. Giving DVCS exposure & enthusiasm (that "could" be deemed as hype, or at least attacked as such), think about the following question when reading this one: "how could I use Gartner's hype cycle to convince management that DVCSs are ready (or ready-enough) for us, and that it is not just hype" Just asking if DVCSs is hype wouldn't be constructive, Gartner's hype cycle is a more objective instrument than just asking that (even if this instrument is regarded as biased). If you know any other instrument please, by all means, mention it. Edit #2: I agree that Gartner's Life Cycle is not for every technology, but I consider it may have generated enough buzz to be considered hype by some, so it maybe deserves to be at least evaluated/pondered as such by using this instrument in order to prove/disprove it to whatever degree. I'm an advocate of DVCS, BTW. I'm doing research for a whitepaper I'm writing in favor of DVCS adoption at company and I stumbled upon the concept of social proof. I want to prove that the social proof of DVCS adoption is not necessarily cargo cult and doing further research I now stumbled upon Gartner's hype cycle which describes technology maturity in 5 phases. My question is: what could be an indicator of the current location of Distributed Version Control Systems (I mean git, mercurial, bazaar, etc. in general) at a particular phase in the hype cycle?... in other (less convoluted) words, would you say that currently expectations of DVCSs are a) starting, b)inflated, c)decreasing (disillusionment), d)increasing (enlightenment) or e)stabilizing (mature) and (more importantly) why? I know it is a hard question and there is subjectivity involved, but I'll grant the answer (and the traditional cookie) to the clearest argument/evidence for a particular phase.

  Read the article

• Expanding existing DVCS Wiki

  - by A Lion

  A portion of my job is to maintain technical documentation for a rapidly expanding manufacturing company. Because it is only a portion of my job and the company's product line is expanding so quickly, I can't stay on top of the documentation. As a result, I've been yearning for an information management system with a handful of specific features. I've found many products that have a subset, but none that have all the features I'm looking for. I'm at the point of picking an existing product and expanding it to cover my desired feature set, however, this will be a pet project and I will be learning the underlying language as I go. So, the main question is which existing product will be the easiest to expand to cover the full feature set and has a relatively easy to learn language? Alternatively, have I missed another existing program that will cover the feature set or should be in my list of "close, but not quite there"? Feature Set web interface based on a distributed version control system (e.g., git) easy to edit by logged in novices (e.g. wiki, multimarkdown) outputs in more traditional formats (e.g., doc, odt, pdf) edits held in queue until editor/engineer/manager approves them (e.g., MS Word editing) [this is the really big elephant in list - suggestions on where to start appreciated] edits held in queue specifically for engineer approval [extra limb of the elephant in the list] well-supported in the open source community Closest, but not quite there ikiwiki - http://ikiwiki.info (php) lots of awesome functionality and extensions, including easy to edit and based on DVCS lacks a review/forward for review queue appears to be well-supported within the OSS community gitit - http://gitit.net/ (haskell) easy to edit and based on DVCS lots of outputs in traditional formats a great web-based gui diff interface lacks a review/forward for review queue appears to be primarily maintained by one individual

  Read the article

• Business case for decentralized version control systems

  - by Keyo

  I searched and couldn't find any business reasons why git/mercurial/bazzr systems are better than centralized systems (subversion, perforce). If you were trying to sell a DVCS to a non-technical person what arguments would you provide for the DVCS increasing profit. I will shortly be pitching git to my manager, it will take some time converting out subversion repositories and some expense in buying smartgit licences.

  Read the article

• Why can Perforce be a better version control system? [closed]

  - by dukeofgaming

  I've seen some people love and some loathe Perforce. As users or administrators with experience with other version control systems (free cookie to the ones with DVCS experience [git, Mercurial]), what is the main reason/feature that makes you love Perforce over other version control systems? Edit: No, I don't sell Perforce... this is just part of my ongoing research to pitch DVCS at my company (see my question history)

  Read the article

• What's so difficult about SVN merges? [closed]

  - by Mason Wheeler

  Possible Duplicate: I’m a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS? Every once in a while, you hear someone saying that distributed version control (Git, HG) is inherently better than centralized version control (like SVN) because merging is difficult and painful in SVN. The thing is, I've never had any trouble with merging in SVN, and since you only ever hear that claim being made by DVCS advocates, and not by actual SVN users, it tends to remind me of those obnoxious commercials on TV where they try to sell you something you don't need by having bumbling actors pretend that the thing you already have and works just fine is incredibly difficult to use. And the use case that's invariably brought up is re-merging a branch, which again reminds me of those strawman product advertisements; if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!) So, discounting the ridiculous strawman use case, what is there in SVN merging that is inherently more difficult than merging in a DVCS system?

  Read the article

1 2 3 4 5 6 7 8  | Next Page >