Well, as I read in some post on merge topic, branching should be used
to start independent lines of development and, sometimes (i.e., not so
frequently), changes made in the trunk are adopted (merged) in a branch
and viceversa.
If branching is used to implements "working areas" for individual developers,
then I think that troubles will arrive in a while.
Even if there is a nice experience report by Patrick Rusk (post on Sept. 3rd)
about merging branches.
Guido.
> -----Original Message-----
> From: Travis P [mailto:svn@castle.fastmail.fm]
> Sent: Thursday, October 07, 2004 6:19 PM
> To: Guido Anzuoni
> Cc: Dianne Chen; users@subversion.tigris.org; Ben Collins-Sussman
> Subject: Re: merge tracking and revision number fragility
>
>
>
> On Oct 7, 2004, at 10:55 AM, Guido Anzuoni wrote:
> > Just a warning about the use of this technique.
> >
> > If the repository is dumped and not fully reloaded
> (starting at some
> > revision) or
> > is loaded into an existing repository with --parent-dir
> switch, then
> > the comment
> > will refer rev. numbers that were valid in the previous
> repository but
> > the
> > actual "playedback" transactions have gengerate different revision
> > numbers.
>
> Yes, though I do record merges as the book suggests, the problem that
> Guido notes has crossed my mind more than once.
>
> It imposes a requirement that all decisions about what
> projects need to
> live in which repositories needs to be made correctly
> the first time because change later will cause big headaches with
> revision numbers in log messages or elsewhere no longer matching.
>
> Example: You have two small server machines serving two repositories,
> but then a big new server is bought and you want to combine the
> repositories for various benefits: can 'svn mv/cp' code between
> projects that used to be impossible because they lived on separate
> repos, can reduce backup and similar administrative overhead because
> just one repos is less work than two. Unfortunately, any combination
> will necessarily cause revnumbers in at least one repository
> to become
> invalid. I'm sure there are a hundred other examples.
>
> Subversion is still new, so I don't think that this problem is being
> encountered today as it will be in the future and large repos are
> merged/separated as hardware changes, management/team/company
> organizational relationships change, geography changes. I
> can imagine
> all kinds of scenarios causing future pain related to this.
>
> This type of "you have to make the decision correctly the first time
> because change later will cause big headaches" problem is
> like to that
> of CVS directory structure which many of us (certainly including
> Subversion developers) dislike intensely.
>
> -Travis Pouarz
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 7 19:09:29 2004