Skip to main content

Home/ dvcs-vs-vcs/ Group items tagged git

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Daniel Jomphe

David Bock's Weblog : Weblog - 0 views

www.jroller.com/...estioning_subversion_practices

comparison dvcs git vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • You see, branches and tags in CVS are different things. But in subversion, they are the same - they are just copies of the trunk into one of those directories. In CVS, these events are temporal... that is, they affect a file at a given point in time. In Subversion, while they still apply to a particular version of a file, branches and tags are spatial... that is, they exist as copies of the trunk, just copied into a specially designated place. This 'branches' and 'tags' convention in subversion is actually limiting, and somewhat false. Since they are really the same thing, I can modify the contents of a 'tag', which is impossible in CVS. I have come to believe that while this convention is useful for projects converted from CVS, it is misleading, limiting, and harmful for new projects. I want a new convention
  • As long as I am coming up with a new convention, what other things might I want to address? First, I like to have a place 'close to the code' where management documents like requirements, meeting minutes, and the like can be stored, but these kinds of things rarely (if ever) need to be branched. I also like Maven's convention that allows for directories of different kinds of source to be part of the same project. Taking all this into account, here is my new convention: /project /code /head /rails /java /versions /design /management
  • Gone are the 'branches' and 'tags' directories, in favor of a single 'versions' directory that should always contain copies of the head with meaningful version names.
Daniel Jomphe

Akademy Redux: Release Team Members Propose New Development Process - 0 views

dot.kde.org/1219926799

comparison dvcs git vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • The centralized development system in Subversion's trunk doesn't support team-based development very well
  • Furthermore we're still looking for more contributors, so lowering the barrier for entry is another important concern.
  • We will have to allow for more diversity and we must be able to accommodate individual workflows.
  • ...15 more annotations...
  • Companies have their schedules and obligations, and what is stable for one user or developer is unsuitable for another.
  • Together with new tools for collaborating, new development models are emerging.
  • And we have an increased need for flexible and efficient collaboration with third parties and other Free Software projects.
  • KDE's development process should be agile, distributed, and trunk freezes should be avoided when possible.
  • We should set up a process aimed at adaptation and flexibility, a process optimized for unplanned change.
  • Currently, our release cycle is limiting, up to the point of almost strangling our development cycle.
  • Our current release process, depicted in the graphic below, can be described as using technical limitations to fix what is essentially a social issue: getting people into "release mode".
  • many developers complain about Subversion making it hard to maintain "work branches" (branches of the code that are used to develop and stabilize new features or larger changes in the code), subsequent code merges are time-consuming and an error-prone process.
  • The proposal would essentially remove these limitations, instead relying on discipline in the community to get everyone on the same page and focus on stability. To facilitate this change, we need to get the users to help us: a testing team establishing a feedback cycle to the developers about the quality and bugs. Using a more distributed development model would allow for more flexibility in working in branches, until they are stabilized enough to be merged back to trunk. Trunk, therefore, has to become more stable and predicable, to allow for branching at essentially any point in time. A set of rules and common understanding of the new role of trunk is needed. Also, as the switch to a distributed version control system (which is pretty much mandatory in this development model) is not as trivial as our previous change in revision control systems, from CVS to Subversion. Good documentation, best practice guides, and the right infrastructure is needed.
  • KDE's current system of alpha, beta and release candidate releases will be replaced by a system which has three milestones:
  • The Publish Milestone This is the moment we ask all developers to publish the branches they want to get merged in trunk before the release. Of course, it is important to have a good overview of the different branches at all times to prevent people from duplicating work and allow testers to help stabilize things. But the "Publish Milestone" is the moment to have a final look at what will be merged, solve issues, give feedback and finally decide what will go in and what not.
  • The Branch Milestone This is the moment we branch from trunk, creating a tree which will be stabilized over the next couple of months until it is ready for release.
  • The "tested" milestone represents the cut-off date. Features that do not meet the criteria at this point will be excluded from the release. The resulting codebase will be released as KDE 4.x.0 and subsequently updated with 4.x.1, 4.x.2, etc. It might be a good idea to appoint someone who will be the maintainer for this release, ensuring timely regular bugfix releases and coordinating backports of fixes that go into trunk.
  • Under discussion are ideas like having some kind of "KDE-next" tree containing the branches which will be merged with trunk soon; or maybe have such trees for each sub-project in KDE. Another question is which criteria branches have to meet to get merged into the "new" trunk.
  • Having a page on TechBase advertising the different branches (including a short explanation of their purpose and information about who's responsible for the work) will go a long way in ensuring discoverability of the now-distributed source trees.
Daniel Jomphe

InfoQ: Distributed Version Control Systems: A Not-So-Quick Guide Through - 0 views

www.infoq.com/dvcs-guide

comparison dvcs git vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
Daniel Jomphe liked it
  • Major reason is that branching is easy but merging is a pain
  • Subversion has no History-aware merge capability, forcing its users to manually track exactly which revisions have been merged between branches making it error-prone.
  • No way to push changes to another user (without submitting to the Central Server).
  • ...4 more annotations...
  • Subversion fails to merge changes when files or directories are renamed.
  • Each working copy is effectively a remoted backup of the codebase and change history, providing natural security against data loss.
  • Experimental branches – creating and destroying branches are simple operations and fast. Collaboration between peers made easy.
  • have a look at
Olivier Valuet

iBanjo » Blog Archive » Version Control and "the 80%" - 0 views

blog.red-bean.com/sussman

comparison dvcs vcs dvcs-vs-vcs

shared by Olivier Valuet on 30 Sep 08 - Cached
  • In 2007, Distributed Version Control Systems (DVCS) are all the range among the alpha-geeks. They’re thrilled with tools like git, mercurial, bazaar-ng, darcs, monotone… and they view Subversion as a dinosaur. Bleeding-edge open source projects are switching to DVCS. Many of these early adopters come off as either incredibly pretentious and self-righteous (like Linus Torvalds!), or are just obnoxious fanboys who love DVCS because it’s new and shiny.
‹ Previous 21 - 33 of 33
Showing 20▼ items per page