Am Dienstag, den 17.04.2007, 16:01 +0000 schrieb ANGonline:
> I have a wrong mind disposition or I misunderstood the philosophy of
> SVN, but what I see is a cooperation problem.
> 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
> the files he's going to amend, and syncronize himself with the other
> developers involved.
> Do you see the problem here?
the common understanding is, that it's rather not the job of the
software to find out about this, i.e. if you need subversion to find out
what (relevant) tasks other people in the team are working on, then your
team's organization and whole philosophy is fundamentaly broken. So
"BEFORE starting to develop", there should be a meeting or email
exchange or chat, so all developers involved know what's going on,
how it should be done and who is to be going to do what.
Having said that -- --
I completely agree with you that such a feature could be usable
sometimes, esp. if you are exploring a new open source project and just
want to learn what was/is going on. Subversion seems inded to have a
certain lack of functionality here (but as mentioned above, this is
not considered very important).
You should note though, that "branching" behaves the same way
as "copying" and "renaming" and "moving", so keeping track
of "all versions in other branches" is much more difficult
as you would mean at first glance.
You should have a look at the GIT version management system,
which is e.g. used for linux kernel developement. They have
much more powerfull history management; you can explore the
whole history graph of every object with all branches and
*all* merges. On the other hand, handling of moves/renames
is much more "hackish" in git and not so deeply rooted in
the core system as in subversion, so for sure there
is a tradeoff.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Apr 17 20:14:25 2007