ANGonline wrote:
>>> Méresse Christophe wrote:
>>> Imagine a software that has 100 source files and a repository
>>> that has one directory for the main trunk and an indefinite
>>> number of directory for all the branches, one for each
>>> ongoing development thread.
>> [snip]
>>
>>> I wonder if there is a way to know, for a certain file, how
>>> many branches have done commits on it (well, to be exact,
>>> commits on its brothers that have been forked while branching).
>> I like when people are lighting this problem because that's the one I'm always complaining about :)
>> No, there aren't any efficient solution and this big issue (from my point of view) does not seem to concern many users...
>>
>> <mode_troll_on reason='tentative to have a real debate on this question and why not some ideas to solve it... :)'>
>>
> Changing this would certainly have a huge impact on the subversion
> core, that's probably the reason why the question always generates a
> big silence :P
>> <mode_troll_off>
>
>> Les Mikesell wrote
>> The point of branching is to isolate changes. Why do it if you want to
>> treat the copies as though they weren't isolated from each other?
>
> Maybe
> I have a wrong mind disposition or I misunderstood the philosophy of
> SVN, but what I see is a cooperation problem. Let me try to explain.
I don't think svn has a philosophy here. You can choose to work
together or in isolation as you please. Branches permit isolation.
Frequent commits/updates to the trunk permit close cooperation.
> Sometimes
> arises the need to start an amendment involving a certain number of
> files that are already under amendment by other developers.
That may or may not be a reason to branch. If the changes eventually
have to be merged, it may be less painful to for everyone to work on the
trunk or the same branch and commit/update frequently.
> This
> usually can be faced at the end, when each branch is merged back, but
> once in a while it happens that the merge is impossibile without
> re-engeneering one or all the amendments (well, it can also happen to
> start develop something that is already under development elsewere).
> This is really really bad and tends to cost too much to be allowed to happen even once in my environment.
>
> I
> think that could be always avoided if each developer, BEFORE starting
> to develop, can go and see what's going on inside the other branches to
> the files he's going to amend, and syncronize himself with the other
> developers involved.
That is the natural course of events if you don't branch. Any update
will pick up everything that anyone else has committed.
> Do you see the problem here?
Sometimes branches are needed because the planned changes are expected
to disrupt the existing structure. If they aren't, they can be more
trouble than they are worth. You don't have to make them just because
the svn documentation says they are cheap.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 17 19:59:28 2007