On Tue, Jan 11, 2011 at 12:36:58PM -0500, NN Ott wrote:
> >
> >
> > >> To recap, as Les put it:
> > >>
> > >> I think the idea is that he'd like to see the development history of
> > both the vendor and local changes as a continuous set of changes as you
> > would if they were in the same repository with log and diff working across
> > any points in time or branch versions. It seems like a reasonable thing to
> > want, but I don't think it is possible with subversion.
> > >
> > >
> >
> > I don't think the request can be met by Subversion. Subversion is a
> > centralized version control system; the request is met by not using a
> > centralized version control system, but instead using a distributed version
> > control system.
> >
> >
> >
>
> With the new merge tracking capability being added, I would think this could
> be on the horizon as well. A full fledged distributed system hardly is
> needed or even what I am looking for.
Merge tracking has nothing to do with this feature request.
> Has such a feature request already been logged?
No, and there is no point in logging it.
The basic concept of a centralized version control system is that a
repository is a single universe. Changes only "happen" in that universe
and you cannot (easily) move or replay changes between universes without
losing the unique identifier the change had in its original universe.
There are some ways of merging repositories, but those require admin access
to the server and are generally not considered normal use cases.
See here: http://subversion.apache.org/faq.html#multi-merge
It sounds like what you really want is commit access to the upstream
Subversion repository, possibly restricted to a special branch.
Then your change identifiers would be in the same universe.
Stefan
Received on 2011-01-11 19:02:43 CET