Jan Friedrich wrote:
Trans schrieb:
In subversion I have never create a branch: It was to expensive for me.
Well, it is cheap in git as it is in svn, the differences are not
there... The distributed/decentralised model is the biggest difference.
--
Posted via http://www.ruby-forum.com/\.
Sorry I spaced and hit send before I actually typed more than my "subject".
I was going to suggest reasons similar to those put forth by Rick.
On 3/12/07, Tanner Burson <tanner.burson@gmail.com> wrote:
On 3/12/07, Glen Holcomb <damnbigman@gmail.com> wrote:
>
> Why not SVN?This is going a bit OT for ruby-talk, but I'll bite.
I work from several different machines, in several different locations,
including from a laptop that is often disconnected from the
internet. It's
extremely useful for me to be able to record changes, branch, work, in my
normal manner, without worrying about the fact that when I DO get a
connection all my changes will show up as one big lump. So I use Darcs
over
SSH. It gives me a full, functional repository with "commits" as I need
them, without being connected. Then when I get back to civilization I can
push all my changes back to my main repo and be good to go, SVN can't give
me that kind of work flow, so I've moved away from it. (I'm aware of SVK,
but never could get it working well on linux/mac/and windows)At work, where I work from a single workstation, always connected to the
network, I use SVN, because it fits the environment better. Use the tool
that fits the job, and move on.On 3/12/07, Trans <transfire@gmail.com> wrote:
> >
> > Should I be using SVN rather than Darcs or Git?
> >
> > Subversion has apparently become the version control system of choice
> > for Ruby developers --especially now that Ruby itself uses it. I
> > suspect that might have a lot to do with Rails and Rubyforge. Ruby
> > only switched over to SVN well after Rails had been using it. And
> > Rubyforge currently only supports SVN and CVS, which I find a bit
> > surprising since, from what I understand, supporting Darcs is just a
> > matter of having Darcs installed. And I can't imagine Git is much
> > different.
> >
> > So I'm wondering, what's so special about SVN as opposed to the other
> > choices? Is it because SVN is more like CVS than the other choices?
> > The fact that SVN isn't distributed I would think would work against
> > it (though I hear SVK is supposed to deal with that). Darcs is written
> > in Haskell, and from the word on the street a lot of Ruby folk seem to
> > like Haskell. Also, Git was written by Linus Torvalds, which is about
> > as good as credentials can get.
> >
> > Thanks,
> > T.
> >
>
> --
> "Hey brother christian with your high and mighty errand, Your actions
> speak
> so loud, I can't hear a word you're saying."
>
> -Greg Graffin (Bad Religion)
>--
===Tanner Burson===
tanner.burson@gmail.com
http://www.tannerburson.com
--
"Hey brother christian with your high and mighty errand, Your actions speak
so loud, I can't hear a word you're saying."
-Greg Graffin (Bad Religion)
Tanner Burson wrote:
At work, where I work from a single workstation, always connected to the
network, I use SVN, because it fits the environment better. Use the tool
that fits the job, and move on.
I agree - and to stress the topic further, there is this site which does
a comparision of version control systems based on features:
I'm using SVN at home and ClearCase at work - in regard to what I know
of both of them the comparison looks sane.
I did choose SVN because I've heard about it. And it does work for me,
so I didn't switch to something else.
Well, and there is
I cannot answer the original posters question, so this is completely
off-topic.
Stefan
> Why not SVN?
This is going a bit OT for ruby-talk, but I'll bite.
To be clear I'm asking why _rubyists_ in particluar choose one over
the other --not so off topic.
I work from several different machines, in several different locations,
including from a laptop that is often disconnected from the internet. It's
extremely useful for me to be able to record changes, branch, work, in my
normal manner, without worrying about the fact that when I DO get a
connection all my changes will show up as one big lump. So I use Darcs over
SSH. It gives me a full, functional repository with "commits" as I need
them, without being connected. Then when I get back to civilization I can
push all my changes back to my main repo and be good to go, SVN can't give
me that kind of work flow, so I've moved away from it. (I'm aware of SVK,
but never could get it working well on linux/mac/and windows)At work, where I work from a single workstation, always connected to the
network, I use SVN, because it fits the environment better. Use the tool
that fits the job, and move on.
So you actually use both. I hate the lack of DRY in that, but it looks
like I may have to go down that road too.
Thanks,
T.
On Mar 12, 3:46 pm, "Tanner Burson" <tanner.bur...@gmail.com> wrote:
On 3/12/07, Glen Holcomb <damnbig...@gmail.com> wrote:
Is this the only real compelling reason to switch to Darcs or similiar
alternatives? For me I'm never off the net long enough for the
centralized repository in svn to become a problem. Even when I'm
working from a laptop most of the day, I'll have free wifi available
somewhere to sync up.
- Rob
On 3/12/07, Tanner Burson <tanner.burson@gmail.com> wrote:
This is going a bit OT for ruby-talk, but I'll bite.
I work from several different machines, in several different locations,
including from a laptop that is often disconnected from the internet. It's
extremely useful for me to be able to record changes, branch, work, in my
normal manner, without worrying about the fact that when I DO get a
connection all my changes will show up as one big lump. So I use Darcs over
SSH. It gives me a full, functional repository with "commits" as I need
them, without being connected. Then when I get back to civilization I can
push all my changes back to my main repo and be good to go, SVN can't give
me that kind of work flow, so I've moved away from it. (I'm aware of SVK,
but never could get it working well on linux/mac/and windows)At work, where I work from a single workstation, always connected to the
network, I use SVN, because it fits the environment better. Use the tool
that fits the job, and move on.
Found this on Wikipedia.
"Many projects support both POSIX and Windows. Such projects typically
avoid using an SCM system that poorly supports Windows, even if most
developers use POSIX-based systems. Examples of projects that have
publicly ruled out any use of git, due to git's poor support of
Windows, include Mozilla [3] and Ruby [4]."
T.
Hi,
In message "Re: Why SVN?" on Wed, 14 Mar 2007 22:16:13 +0900, "Trans" <transfire@gmail.com> writes:
Cool. So how do you sync back up with the SVN repo? I tried using SVN
and Darcs on the same project and ran into problems. Maybe it's not a
problem with Git? Or do you have to do something special?
I used tailor to import repository from svn to git. After that, I
have a directory that have both .svn and .git sub-directories. Maybe
git-svn would do better job.
matz.
Hi,
In message "Re: Why SVN?" on Wed, 14 Mar 2007 19:07:15 +0900, "Rick DeNatale" <rick.denatale@gmail.com> writes:
For your information, I use stgit for managing my local Ruby
repository. IOh oh, Matz, you're going to get the pythonistas all excited <G>
I don't want to have prejudice against tools by the language they are
written, until I have to hack them. I abandoned tailor (and svk) for
that exact reason.
matz.
Careful who you call troll. You'll find your assumption comes back to bite you.
Technology is proven by (1) wide use and (2) long experience. CVS and
Subversion at this point are proven technologies that are widely
adopted. That doesn't necessarily make them best of class, but it
means that people know what to expect from them. Some of that will
include bugs, but the core technology is proven. There are billions of
lines of code in CVS and Subversion systems being protected and
managed right now.
Subversion has meaningfully improved upon CVS and has improved the
state of the art for open source centralized source management. I
wouldn't dare call it best of class, but I would use it for any open
source project because it (1) has a lower barrier of entry across
platforms and (2) works in ways that people expect it to. I'm less
convinced that I'd use it for professional software development after
my experience with Perforce at my current job. Perforce is an
absolutely amazing piece of software that gives many of the supposed
benefits of distributed development platforms (lightweight branches,
patch cherry picking), and with p4proxy, you get better distributed
development (although *not* apparently disconnected distributed
development).
There's so many different distributed systems right now that work
differently from each other and have forked because of differences in
opinion on how the programs should work that it's nearly impossible to
choose one reliably. Many of them suffer from an extreme anti-Windows
bias and very few of them (if any!) have GUI support for visualizing
changes over time. I personally find disconnected distributed version
control systems to be very fragile in that entire branches can go away
because a middle version is purposefully or accidentally deleted.
People say that distributed systems have cheap branching, but I find
that very hard to believe, since (at least in the ones that I've
tried, and I have a hard time imagining how others would differ) the
branches are physical copies in a different location. That's cheap for
the making, yes, but your total storage cost goes up (since none of
the advantages of having a single repository can be found) and it then
becomes possible to *lose* branches from your repository (cf fragility
above).
There's a lot of things to like about the *ideas* of DDSCM, but in the
real world, I find that I'm rarely disconnected from the 'net long
enough to care about the fact that I'm using a centralised management
system.
So no, not a troll. Well informed using shorthands that should have
been pretty easy to determine if you weren't blinkered by the
proponents of DDSCM in the first place.
-austin
On 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
I can't resist replying to this troll. I call FUD on the "distributed
version control systems without much proven technology behind them"
claim until we get details. I'd really like to hear why you think you
have a winner just because something is different. It's obvious you
think you have a great reason to feel strongly about using Subversion.
I think it is only fair that you share why if you plan on telling
people such absolutes. So please, enlighten me.
Working offline is not the only situation where a distributed version
control system may be better. How about the following situation.
Developer A is working on a major task. He has already changed a lot
of software locally. Now A gets aware that he needs B doing some
modifications in some other modules where B is the real expert.
Neither A nor B can propagate his own changes solely, because that
would break the build for all other developers. This is a normal
branch situation, but the branch situation has been recognized very
late. In addition A and B have to work some more time on the common
task, which means that they have to interchange and synchronize their
software releases several times without disturbing the others.
In a distributed system A and B just pull from each other as often as
they need to get the task done. Full propagation (resp. integration,
in a central system) will follow then, but not earlier.
Regards
Thomas
"Tim Becker" <a2800276@gmail.com> wrote/schrieb <254c7bfb0703121526r57c6d198t9234c5ad501a89f6@mail.gmail.com>:
working offline is, with the exception of maybe a short stint on a
plane or train, not that common nowadays.
Austin a TROLL??? Well maybe he has adopted a troll like language but
I believe that you should see the context of all his contributions.
I defend him because I dislike him a lot and I find his Unix hatery
quite boring.
BUT he is a very valuable contributor.
So consider twice putting him into your kill file.
And yes of course Austin you have the right to holler at me, I was
quite harsh...
On 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
On 3/14/07, Austin Ziegler <halostatue@gmail.com> wrote:
> On 3/12/07, Trans <transfire@gmail.com> wrote:
> > Should I be using SVN rather than Darcs or Git?
>
> Yes.
>
> Darcs and Git are distributed version control systems without much
> proven technology behind them, and are painfully Unix-oriented.
>
> > So I'm wondering, what's so special about SVN as opposed to the other
> > choices? Is it because SVN is more like CVS than the other choices?
> > The fact that SVN isn't distributed I would think would work against
> > it (though I hear SVK is supposed to deal with that). Darcs is written
> > in Haskell, and from the word on the street a lot of Ruby folk seem to
> > like Haskell. Also, Git was written by Linus Torvalds, which is about
> > as good as credentials can get.
>
> Quality in kernel management doesn't mean his version control system
> is any good. I'm not saying it's bad -- at all -- but the credentials
> don't transfer there.
>
> Distributed systems fit very few development models.
>
> -austinI can't resist replying to this troll. I call FUD on the "distributed
version control systems without much proven technology behind them"
claim until we get details. I'd really like to hear why you think you
have a winner just because something is different. It's obvious you
think you have a great reason to feel strongly about using Subversion.
I think it is only fair that you share why if you plan on telling
people such absolutes. So please, enlighten me.Brian.
--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw
I would agree with a picture like that 
I mostly only check out projects, and recently I saw some that switched to git.
From the checkout/compile point of view git is pretty much the same as
cvs. But once I had to make a modification it became different. In the
end I found working with the modifications easier and cleaner.
However, I would be very disappointed if I found myself on Windows and
could not use git because of that.
The possibility of working offline is important for people who have
experience with crappy net coverage. I would count myself in, but I
understand that in some places such issues are nonexistent.
It looks like the distributed systems are new and more powerful which
means people have to get used to it. And many probably never will.
Also some features like crossplatform support have to be ironed out.
So I would guess the only reason to use them right now would be
experimenting or some features that are not easily obtained elsewhere.
Thanks
Michal
On 3/12/07, Trans <transfire@gmail.com> wrote:
See now this is interesting. Cause I feeling inclined toward Git for
these same reasons. In fact here's a diagram of me being torn:I, Torn
O
SVN <-- --|-- --> Git
/ \
Solid Darcs Faster
Popular Stronger
Supported BetterNot that Darcs hasn't been good to me.
Ollivier Robert wrote:
Well, it is cheap in git as it is in svn, the differences are not
there...
The main difference is for me that in svn the branch is a part of the
hole history of the repository while in git a can simple delete a branch
and it is not any more existent. Therefore I use it in many cases when I
don't know if an idea is best way to solve a particular problem. If I
want to do it this way, I merge it to the master and delete the
temporary branch. Otherwise I delete the branch also and don't see it
again. This is my definition of cheap: temporary branches.
--
Posted via http://www.ruby-forum.com/\.
In my experience that isn't really true -- git has much better merge tracking than svn, so repeated merges on long-lived branches are substantially less painful with git.
-mental
On Tue, 3 Apr 2007 23:41:14 +0900, Ollivier Robert <keltia@gmail.com> wrote:
Jan Friedrich wrote:
Trans schrieb:
In subversion I have never create a branch: It was to expensive for me.Well, it is cheap in git as it is in svn, the differences are not
there...
>
> > Why not SVN?
>
> This is going a bit OT for ruby-talk, but I'll bite.To be clear I'm asking why _rubyists_ in particluar choose one over
the other --not so off topic.> I work from several different machines, in several different locations,
> including from a laptop that is often disconnected from the internet. It's
> extremely useful for me to be able to record changes, branch, work, in my
> normal manner, without worrying about the fact that when I DO get a
> connection all my changes will show up as one big lump. So I use Darcs over
> SSH. It gives me a full, functional repository with "commits" as I need
> them, without being connected. Then when I get back to civilization I can
> push all my changes back to my main repo and be good to go, SVN can't give
> me that kind of work flow, so I've moved away from it. (I'm aware of SVK,
> but never could get it working well on linux/mac/and windows)
>
> At work, where I work from a single workstation, always connected to the
> network, I use SVN, because it fits the environment better. Use the tool
> that fits the job, and move on.So you actually use both. I hate the lack of DRY in that, but it looks
like I may have to go down that road too.
Yes indeed, what is happening in the Ruby community is happening all
over the place.
SVN will simply replace CVS slowely but surely.
Thanks,
T.
Cheers
Robert
On 3/12/07, Trans <transfire@gmail.com> wrote:
On Mar 12, 3:46 pm, "Tanner Burson" <tanner.bur...@gmail.com> wrote:
> On 3/12/07, Glen Holcomb <damnbig...@gmail.com> wrote:
--
We have not succeeded in answering all of our questions.
In fact, in some ways, we are more confused than ever.
But we feel we are confused on a higher level and about more important things.
-Anonymous
This is going a bit OT for ruby-talk, but I'll bite.
I work from several different machines, in several different locations,
including from a laptop that is often disconnected from the internet. It's
extremely useful for me to be able to record changes, branch, work, in my
normal manner, without worrying about the fact that when I DO get a
connection all my changes will show up as one big lump. So I use Darcs over
SSH. It gives me a full, functional repository with "commits" as I need
them, without being connected. Then when I get back to civilization I can
push all my changes back to my main repo and be good to go, SVN can't give
me that kind of work flow, so I've moved away from it. (I'm aware of SVK,
but never could get it working well on linux/mac/and windows)At work, where I work from a single workstation, always connected to the
network, I use SVN, because it fits the environment better. Use the tool
that fits the job, and move on.Is this the only real compelling reason to switch to Darcs or similiar
alternatives? For me I'm never off the net long enough for the
centralized repository in svn to become a problem. Even when I'm
working from a laptop most of the day, I'll have free wifi available
somewhere to sync up.
The ability to cherry pick patches is also a real benefit.
--jer
On 12-Mar-07, at 7:07 PM, Rob Sanheim wrote:
On 3/12/07, Tanner Burson <tanner.burson@gmail.com> wrote:
- Rob
!DSPAM:45f5dd16205594666221374!
Rob Sanheim wrote the following on 13.03.2007 00:07 :
This is going a bit OT for ruby-talk, but I'll bite.
I work from several different machines, in several different locations,
including from a laptop that is often disconnected from the
internet. It's
extremely useful for me to be able to record changes, branch, work,
in my
normal manner, without worrying about the fact that when I DO get a
connection all my changes will show up as one big lump. So I use
Darcs over
SSH. It gives me a full, functional repository with "commits" as I need
them, without being connected. Then when I get back to civilization
I can
push all my changes back to my main repo and be good to go, SVN can't
give
me that kind of work flow, so I've moved away from it. (I'm aware of
SVK,
but never could get it working well on linux/mac/and windows)At work, where I work from a single workstation, always connected to the
network, I use SVN, because it fits the environment better. Use the
tool
that fits the job, and move on.Is this the only real compelling reason to switch to Darcs or similiar
alternatives? For me I'm never off the net long enough for the
centralized repository in svn to become a problem. Even when I'm
working from a laptop most of the day, I'll have free wifi available
somewhere to sync up.
I'm currently looking at decentralized version control systems for my
own needs. So it's my early ideas on the subject, feel free to correct
them...
Where it can help is when a developper has a bright idea and want to
implement it without impacting others. She creates a branch on her local
repository to try out her idea and work with it (and can do for a
longtime, merging patches from the branch she follows usually along the
way). If you often have ideas being tried out, it can be a benefit
because these branches would all be cluttering your common repository
with a centralized system (this is why you can have lots of Linux kernel
trees with git, each with its own purpose, the most popular by far being
Linus Torvalds' one).
This probably is a real benefit when you have lots of really good devs
all motivated to try out their ideas. This allows large group of
developpers to scale.
Lionel.
On 3/12/07, Tanner Burson <tanner.burson@gmail.com> wrote:
> I can't resist replying to this troll. I call FUD on the "distributed
> version control systems without much proven technology behind them"
> claim until we get details. I'd really like to hear why you think you
> have a winner just because something is different. It's obvious you
> think you have a great reason to feel strongly about using Subversion.
> I think it is only fair that you share why if you plan on telling
> people such absolutes. So please, enlighten me.Careful who you call troll. You'll find your assumption comes back to bite you.
I knew I could count on a good reply. I know you are a good debater. I
need not bring up the topic of benchmarking with you for example. 
Technology is proven by (1) wide use and (2) long experience. CVS and
Subversion at this point are proven technologies that are widely
adopted. That doesn't necessarily make them best of class, but it
means that people know what to expect from them. Some of that will
include bugs, but the core technology is proven. There are billions of
lines of code in CVS and Subversion systems being protected and
managed right now.
Yes. Though there a millions of lines of code written in languages a
lot here would consider primitive. There are also millions of more
lines of code being written with no version control as well (I would
guess, though there is no denying that this number is larger than it
should be). I think I will agree that the wide spread use is
important, but I don't think adoption is the only metric to look at.
Subversion has meaningfully improved upon CVS and has improved the
state of the art for open source centralized source management. I
wouldn't dare call it best of class, but I would use it for any open
source project because it (1) has a lower barrier of entry across
platforms and (2) works in ways that people expect it to. I'm less
convinced that I'd use it for professional software development after
my experience with Perforce at my current job. Perforce is an
absolutely amazing piece of software that gives many of the supposed
benefits of distributed development platforms (lightweight branches,
patch cherry picking), and with p4proxy, you get better distributed
development (although *not* apparently disconnected distributed
development).
No argument here. There are a lot of projects that thrive off of easy
entry. I think Ruby on Rails is an excellent example that many in this
community have been influenced by. I hear more and more people taking
up Subversion because of how pleasantly it works with the rails
development environment.
Professionally, I use subversion, though my team is looking to migrate
to something that does a better job at branch management and merging.
The verdict hasn't been given yet, but it will likely also be
distributed. Your review (and the reviews of others in this community)
might make an impact. I will likely give Perforce another shot (though
I know the team I work with is much more likely to want something open
source).
The important thing here is, for those of us who can afford to learn a
new tool (effort required here is usually exaggerated), the history of
a tool is a smaller barrier to entry (provided it works correctly). I
am much more likely to pick up an alternative in some of my projects
because of this.
There's so many different distributed systems right now that work
differently from each other and have forked because of differences in
opinion on how the programs should work that it's nearly impossible to
choose one reliably. Many of them suffer from an extreme anti-Windows
bias and very few of them (if any!) have GUI support for visualizing
changes over time. I personally find disconnected distributed version
control systems to be very fragile in that entire branches can go away
because a middle version is purposefully or accidentally deleted.
People say that distributed systems have cheap branching, but I find
that very hard to believe, since (at least in the ones that I've
tried, and I have a hard time imagining how others would differ) the
branches are physical copies in a different location. That's cheap for
the making, yes, but your total storage cost goes up (since none of
the advantages of having a single repository can be found) and it then
becomes possible to *lose* branches from your repository (cf fragility
above).
I have to admit that none of the people I work with write their code
in a Windows environment. In fact, as a team, we officially don't
support it. The only windows environments we have left are for testing
some of the web applications in Internet Explorer. This would probably
count as a bit of context I guess.
I will note that I've never had a branch problem, though I guess it
depends on how you manage your code. I usually have very little that
could be lost if I, for some reason, wanted to rm -rf a working copy.
I think most of this is helped by following a set of conventions for
each tool. There is a reason subversion makes use of the
trunk-tag-branch structure... and there are similar reasons that
people work certain ways with other tools. I usually have a couple
places I put code depending on the project type. In many cases, I
setup my environment with a central repository that represents
something like a trunk. Real development is done outside of the trunk
but synced in functional groups. Locally, small changes are recorded
quite often (this accentuates the power of cherry picking in an
interactive system). It seems that this duplication gives it the same
"relative" reliability that a standard Subversion setup would have
(detached code repo being one if you have multiple machines).
For cheap branches... I'm not sure either. It has always boggled my
mind why people are so upset when two files have to be duplicated. One
system that really does cheap branching well is git. Only a single
file with a few characters is created for each branch (initially,
changes are added of course). I'd love to hear from others who know
more about this.
There's a lot of things to like about the *ideas* of DDSCM, but in the
real world, I find that I'm rarely disconnected from the 'net long
enough to care about the fact that I'm using a centralised management
system.
True enough. I like some of the ideas because I am one of those people
who has experienced significant offline development. Maybe it
conditioned me to where I am now.
So no, not a troll. Well informed using shorthands that should have
been pretty easy to determine if you weren't blinkered by the
proponents of DDSCM in the first place.
Yes. I know I lean far to the DDSCM side of things and I don't intend
to hide it. I think the quality of this reply made up for the
originally open claims. Though, I would like to ask, out of all the
problems you mention, none of them really give a benchmark that could
be used to note if a DDSCM would be ready under your definitions, are
there any specific things that could be fixed or done to make your
trust in a DDSCM system more likely? Or is DDSCM, for some reason,
mutually exclusive with what you get out of your current SCM usage?
Thanks,
Brian.
On 3/14/07, Austin Ziegler <halostatue@gmail.com> wrote:
On 3/14/07, Brian Mitchell <binary42@gmail.com> wrote:
I have actually given that some thought. While not the case presently,
I think eventually this will become a mute point. Ultimately file
systems themselves will manage data redundancy. I think of it as
"holographic" memory. I don't know why exactly as it has nothing much
to do with actual holographs, but it sounds cool
For fun I started writing a version control system in Ruby just to get
a better understanding of the concepts. Turns out not to be so hard
really --at least for a simple model.
In any case, as far your advice. I'm taking it, but with Matz' twist.
My two main projects consist of many subprojects. I figure I can use
Subversion on the project as a whole, but Git on each subproject. Well
that's the theory. Let you know how it goes.
T.
On Mar 14, 9:07 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:
People say that distributed systems have cheap branching, but I find
that very hard to believe, since (at least in the ones that I've
tried, and I have a hard time imagining how others would differ) the
branches are physical copies in a different location. That's cheap for
the making, yes, but your total storage cost goes up (since none of
the advantages of having a single repository can be found) and it then
becomes possible to *lose* branches from your repository (cf fragility
above).
I'm just learning SVN, but can't this problem be handled as follows:
- Create a branch in the repository
- Developer A uses svn switch to associate their local files with the new branch
- Developer A commits their changes to the branch
- Developer B checks out the branch
I'm not trying to make any point re: distributed vs centralized repositories
I'm just trying to determine if I understand how this might be handled in SVN.
Gary Wright
On Mar 18, 2007, at 5:45 PM, Thomas Hafner wrote:
Developer A is working on a major task. He has already changed a lot
of software locally. Now A gets aware that he needs B doing some
modifications in some other modules where B is the real expert.
Neither A nor B can propagate his own changes solely, because that
would break the build for all other developers. This is a normal
branch situation, but the branch situation has been recognized very
late. In addition A and B have to work some more time on the common
task, which means that they have to interchange and synchronize their
software releases several times without disturbing the others.