[snip]
> >>> We have very well defined requirements for each release. And if we
> >>> adopt this branching scheme, we will have in our repository
> >>>
> >>> Repo/application/
> >>> release1/
> >>> release2/
> >>> release3/
> >>> ...
> >>>
> >>> So developers are very clear where they should be working.
> >> And once a
> >>> release dir (branch) is created the development for that release
> >>> always stays on the same branch (and doesn't at some point
> >> jump to a
> >>> release branch).
> >>>
> >>> Yes, R1 changes have to get propagated to R2, R2 to R3, etc. We do
> >>> this my merging R1 -> R2 -> R3, etc.
> >> Doesn't that lose a lot of the development history log
> >> compared to doing
> >> all pre-release work that doesn't absolutely have to
> isolate your
> >> developers on the trunk and branching only when it is time to
> >> stabilize
> >> the releases?
> >
> > I don't know what is meant by "losing development history log". You
> > can always look at the history of the top level "application"
> > directory.
>
> If you look at a file in the 'release3' branch, can you see all the
> individual commits in its history with useful comments as you
> would if
> you did all the work in the trunk and viewed from there or
> just a bunch
> of 'merged from' aggregates for the changes done elsewhere?
>
No, I don't think so, not if you look in the release3. However, you
invoke "svn log --verbose" on the "application" directory, you'll see
all revisions from the time the application was created. You would have
to grep for entries containing the object that you are interested in.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 30 15:38:39 2007