On Tue, Jan 11, 2011 at 1:02 PM, Stefan Sperling <s...@elego.de> wrote:
> 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. > > > 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. > > I just want the svn copy/log/diff/merge logic to see past, and account for, and svn:external barrier. Very much a one-way flow of changes. Imho, doesn't seem too bizzare or non-svn like. How is the external svn rev number + repo info not enough to enable the sort of local tracking of copy+merge this would require?
