Thomas Lehmann wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
Please don't post html messages. I can just barely read the result!
Also it is against published mailing list policy:
http://subversion.tigris.org/mailing-list-guidelines.html
Please use ASCII or ISO-8859 text if possible. Don't post HTML
mails, RichText mails, or other formats that might be opaque to
text-only mailreaders.
> Bob Proulx schrieb:
> > Are developers working on the main trunk or working on a private
> > branch?
> private branch!<br>
Okay. A common paradigm.
> I don't understand your comment about global version numbers. Every
> > commit does increment the repositories last commit revision. But that
> > has nothing to do with merging commits to a release branch. Those are
> > completely separate concepts.
> </pre>
> </blockquote>
> I meant "global" because the revision increases independent of being in
> main or a private branch!<br>
Yes. That is completely correct. But also completely
inconsequential. It is a common misconception that it is a problem
however because people coming from rcs or cvs have not experienced it
before. But trust me, this has been discussed a lot and having global
revision numbers is a "Good Thing".
> > You can merge whatever you want onto a release branch. You can merge
> > everything. Or you can "cherry-pick" particular changes. It is all
> > your choice.
>
> Yes - my choice - but it's important how much it costs to do so:<br>
> <br>
> Example:<br>
> <br>
> 10 Developers are working more or less independently on their projects
> and they will continuiously<br>
> merging into the development line to keep it up to date. At any time
> (maybe some months later)<br>
> individual developers are told to merge specific projects into the
> release.<br>
You don't want to go too long without merging. The longer you let
things go then the more differences will occur between a development
stream and the previous release stream. Especially with a lot of
developers there will tend to be overlap unless discipline is used to
maintain the areas of modifications in separate areas of the project.
> Solutions:<br>
> 1) Every project is a branch but that does also mean: corrections in
> the context of an issue tracker<br>
> needing 2 hours of fixing and testing are also a branch - how many
> branches has to be managed<br>
> then -> 20, 50, 100, ... 10000 -> Is this what we want to
> have?<br>
> Advantage: It's much easier to find out what to merge (thanks to
> the help as explained by last mail)<br>
I personally like developing on a branch. But I will try to keep the
number of those branches contained. For example on one project that I
am working I have five concurrent branches going. I consider that a
lot although I am sure that there are people on the list that will say
that is a small number. I just can't keep more than that in my head
anymore. Therefore I will have to actually finish a task and close
out that branch entirely before starting another. Like a juggler I
can only keep so many balls in the air at a time. My goal is to have
no more than one development branch open at a time for my personal
development.
If you are thinking that you will have a zillion branches then I worry
that this will bring nothing but trouble. They are really not
independent because all need to track the main trunk and the main
trunk needs to track back from them.
> 2) Each developer removes temporary branches after committing and each
> revision until the<br>
> deletion of a branch must be remebered! (so we can start individual
> merges) -> many work!!!!<br>
Yes. Exactly!
> Hown about the tracking feature? Future enhancement for subversion or
> always client stuff<br>
> like the script you told me?<br>
It is on the Subversion development roadmap. I see on the development
mailing list that work is starting to happen on it. But when will it
be available in a usable form? I can't guess. But probably not this
year. Maybe next year, at a guess. I really don't know and can't
guess these things very accurately. Until then it is either manually
tracking or using the svnmerge script.
> Now the problem is to merge those changes back into the main trunk.
> Did you note down the version when the branch was created? No? Then
> look for it in the log.
>
> svn log --stop-on-copy
>
> svn switch $URL/trunk
> svn merge -r564:579 $URL/branches/task-branch .
> svn commit -m"Merged task-branch changes r564:579 into the trunk."
> </pre>
> </blockquote>
> Yes - fine! It sounds reasonable (and the only practicable) but not the
> best solution I would think about!<br>
> I think we can live with it (actually).
Most of us would like a better solution too.
> Could you give a hint on how to reduce the amount of temporary
> branches?<br>
This is a topic that perhaps others on the list can help with. Help!
But you will need to give more information on how you expect your work
flow to operate. Will the person fixing a bug also be merging the fix
back into the main trunk? How about someone adding a feature? Or
will they need a different person to review their changes and to pull
those changes into the main trunk. In my projects I am fortunately
able to do both operations.
The best I can advise is to keep things simple. I try to start a task
and finish a task within a short time. I create a branch, make my
changes, test and verify, commit, test and verify, cleanup. If I get
interrupted with a higher priority fix then I will start an additional
branch for that fix and push it through to finish and then return to
the previous development. My goal is to only have one outstanding
development branch. Other people may have other operating modes.
Hope this helps,
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 18 06:46:05 2006