search for: dvcs

Hi, I have been looking at mirroring the SVN R repository into a DVCS (Mercurial, Git, bzr, etc...). The idea would be to have that as an always up-to-date untouched master (a mirror) but having it in a DVCS would make forks easier to make and maintain, and possibly ease up the process of having patches included upstream. Would anyone else be interested ? Lau...

Recently, I've been working on tools for doing high-quality conversions of project histories from centralized version-control systems like Subversion to modern decentralized systems like git and hg. To see what I mean by "high quality", take a look at my DVCS migration guide: <http://www.catb.org/esr/dvcs-migration-guide.html>. A really good conversion should, for example, rescue references like "r2317" in commit comments so that they still point at the right changesets inb the new system. In order to improve my tools, I've been ac...

Hi, Just wondering whether anyone had thought about moving the R sources to a "distributed" version control system such as Bazaar, Git or Mercurial. These new generation systems make it easier to work on feature branches, allow working offline, are very fast, etc. Some projects that have moved to Git are Linux Kernel Perl Ruby on Rails ... http://en.wikipedia.org/wiki/Git_(software)

...or giving you a fuzzy idea about how that change relates to other changes wrt the order it was applied and, similarly, the approximate timeline. The usefulness of having this information on an immediate form is amplified by *not* appreciating the advantages of a distributed version control system (DVCS). Once the community starts using DVCS, answering the question "is revision X in branch Y?" will be far more important, and that is something that a monotonically increasing revision number do not solve. I understand your views and doubts, because I had the same ones at some point on the...

...stream nearly trivially with git. With svn it is unpleasent, to say the least. The centralized model is in many ways completely wrong for a codebase like LLVM which is explicitly expected to be forked and enhanced in proprietary ways. By definition there will be many copies of the repository. A DVCS allows everyone to keep those copies in sync. To me this is the killer feature of any DVCS. > If the argument is better branching, I would like to see it clarified > for how this improves the workflow. I often come across the case where I want to share some changes with a few colleagues bu...

...hat the trunk >> branch is the only one needing QA attention. Migration from SVN to Git >> is hard because you have to change the mental model, not just command >> names and how revisions are named. > > > You've mistaken me for someone who doesn't understand why DVCS is important. Please stop using this list to evangelize git. > > My point is that we have QA and release engineering processes that work on each branch independently and work best with chronological build #s *per branch*. > > I would like to think that git generation numbers are suffi...

Hi, Quite a few people have asked to be able to access OpenSSH sources using a DVCS, so I have made a Mercurial repository available at http://hg.mindrot.org/openssh You can fetch a copy using: hg clone http://hg.mindrot.org/openssh openssh You can also view the web interface directly, which might be handy for fetching diffs of changesets to cherry-pick. The repository is...

...it. With svn it is > unpleasent, to say the least. > > The centralized model is in many ways completely wrong for a codebase > like LLVM which is explicitly expected to be forked and enhanced in > proprietary ways. By definition there will be many copies of the > repository. A DVCS allows everyone to keep those copies in sync. > > To me this is the killer feature of any DVCS. This is great, sounds like a handy feature, but I really don't care. We are not fundamentally changing the development policy around LLVM. This policy centers around small and incremental c...

...ttner <clattner at apple.com> writes: > I really do appreciate distributed VCS, but only as staging. > Incremental development is crucial for the project and "take this git > push with 100K of code" will never be acceptable. Incremental development is probably promoted by DVCS far more than others. Your comment seems to imply that only the tip of each push is important. In the Git world, it usually isn't. The flow promoted by Git is precisely to make sure each and every commit passes the tests. So, the granularity of "incremental development" is really the...

...kernel -- but I don't think that's a sane development model and I certainly don't see that agreeing with the development policy of LLVM. If the argument is doing detached development, that is already possible. Approaches include the Git mirror, SVN mirroring solutions etc. Advocats of DVCS tend to ignore the cost of the move. The linear commit graph and associated properties is the biggest one. This can be dealt with as part of a defined workflow, but that is far more work than just saying "use tool XXX" and I don't see this happening yet. At least on that point, we bot...

...mercurial? > > I am not as "current" on git wizardry as I am on mercurial, but at I > least verified that branched development and rebasing to tip, r-w- > works on the mercurial-svn bridge (i.e. you can commit directly to svn > via hg and gain all of the benefits of using a dvcs) git-svn allows commits to svn directly from git. But you need to make sure the history in the branch you dcommit from is "linear." As you say, a rebase is always necessary while with "normal" git it is optional. The practical consequence of this is that the developer has to...

...t; Have you considered mercurial? I am not as "current" on git wizardry as I am on mercurial, but at I least verified that branched development and rebasing to tip, r-w- works on the mercurial-svn bridge (i.e. you can commit directly to svn via hg and gain all of the benefits of using a dvcs) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/094da3cc/attachment.html>

..., on terms of developer workflow, group management, etc. We should make those details explicit just to avoid surprises. I was involved on the Emacs transition to Bazaar from CVS. Converting the repositories was a minor task in comparison to the educational effort to adapt people's mindset to a DVCS. Some years after the migration, people is still not thinking on terms of a DVCS, making fundamental mistakes along the way. LLVM developers have a very different profile and I'm sure that things will settle down after just a few rough weeks if the right decisions are made from the start.

On Jul 22, 2011, at 3:45 PM, Bob Wilson wrote: > > On Jul 22, 2011, at 3:33 PM, fly language wrote: > >> >> After git, mainline will still be the most important branch for the *project*, >> but you will work with quite a few branches on parallel. >> >> >> Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the

...and Distributed Version Control (GIT) Systems Impact Software Changes? (22 Citations; Published: 2014) ########################################################################################################################################## 1.1 Paper Conclusions We found that the use of CVCS and DVCS have observable effects on developers, teams and processes. The most surprising findings are that (i) the size of commits in DVCS was smaller than in CVCS, (ii) developers split commits (group changes by intent) more often in DVCS, and (iii) DVCS commits are more likely to reference issue tracking...

> After git, mainline will still be the most important branch for the > *project*, > but you will work with quite a few branches on parallel. > > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". The git workflow works really really great, but it does require getting rid of mainline thinking. It doesn't exist.

> > > Besides, the git-svn readonly bridge is a great solution for those who want > to use git > It seems to be a reasonable solution for those individuals who want to use git, but in my experience not for organizations that want to use git, e.g. have a local server with local branches, with many people banging on that while at the same time continuously merging the LLVM mainline

UNBIASED FACTS: ? Bugzilla & R-devel Mailing Lists: Remain unchanged: Understood as Ticketing platforms for bug pull requests on the R-devel Git Repository. ? Git Repository Options: A) Github (Cloud with Automated backups from GitHub to CRAN Server): https://github.com B) Gitlab (Selfhosted on CRAN): https://about.gitlab.com C) Phabricator (Selfhosted on CRAN): https://www.phacility.com D)

...e wrong time. There is no easy way of fixing this other than to delete the entire build tree and start again. > > I think svn works better than git as an authoritative upstream > > Would you mind expanding on this? What problem specifically is being solved? Linus and Guido both use DVCS's and the authoritative upstream is whatever URL the BDFL says it is. Monotonic version numbers are the biggest advantage. It is easy to see that r1234432 contains the bug fix introduced in r1234430. It is very hard to see if version 23bef194ac contains the bug fix added in 23bef19412. This...

...ision numbers] are welcome. Oh, I really doubt that's true. I'm a big Mercurial proponent, c.f. ... <http://jhw.dreamwidth.org/1868.html> <http://jhw.dreamwidth.org/2049.html> ...but even I know when to shut up and just go along to get along. If folks want LLVM to use a DVCS instead of Subversion, then I will be cheering from the sidelines if LLVM switches to Git. For my purposes, I'll just use the HgGit extension <http://mercurial.selenic.com/wiki/HgGit> as my view on the Git repository. I use that routinely with other projects that use Git as their author...