search for: advocat

...n the Linux 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 poin...

...opment policy is insane. And they have a history of success to back up their claims. > If the argument is doing detached development, that is already possible. > Approaches include the Git mirror, SVN mirroring solutions etc. Slow, so done less often than what people would want to do. > Advocats of DVCS tend to ignore the cost of the move. The linear commit > graph and associated properties is the biggest one. You don't have a linear commit graph unless you disallow merges in the project policy. Independently of whether you use svn or git. svn does present you with a "trunk&...

fly language <flylanguage at gmail.com> writes: >> 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

...e 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 but don't want to push it to "mainline" for fear of disturbing too many people. Local branches are great for this kind of thing. > Advocats of DVCS tend to ignore the cost of the move. The linear commit > graph and associated properties is the biggest one. I think the linear commit graph is in many ways misleading. As has been pointed out, it is common to think "r33423" implies every change before that, but it does not....

> 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.

...t shows those commits as part of a logically consistent series and giving the precise point where the feature was incorporated into mainline. > 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. I'm not ignoring it. Actually, I'm one of those who are warning against the "let's migrate the infraestructure and then all will be a path of roses" view. > The linear commit > graph and associated properties is the biggest...