"Eric S. Raymond" <esr@thyrsus.com> wrote on 09/16/2004 12:40:17 PM:
> Mark Phippard <MarkP@softlanding.com>:
> > > I have precious little interest in seeing Subversion become a
> > > decentralized version control system. So "syncing repositories"
> > > transforms in my mind to "unidirectionally syncing read-only slave
> > > repositories with a single master repository", and for that purpose
> > > the existing dump format, as-is, is perfect.
>
> > Obviously our main problem currently is that we are essentially doing
a
> > lot of work without any version control because we have no place to
> > commit. All we can do currently is make patches on a regular basis
and
> > archive them. Yes, we could solve the problem by having an EBCDIC
branch
> > in the actual repository, but lets just assume that is not an option.
>
> Heh. First you say you have little interest in seeing Subversion
> become a decentralized version control system. then you present a use
> case that really wants exactly that.
>
The first quote was from cmpilato not me, I am not exactly sure what I
want. I mainly want a system exactly like Subversion, it is just that I
see scenarios where these other needs pop in. When I think of a
decentralized system, I think of the decentralization extending down to
the individual prgorammer. What I want is more at the repository level.
In other words, there are the central Subversion, TortoiseSVN and
Subclipse repositories with hundreds of programmers working with them, and
there is my repository which can pull in changes from those repositories,
but otherwise serves a pool of programmers on my end. From the point of
view of the programmers on my end they are using Subversion like anyone
else would -- against a central repository. It is just that there is this
"virtual programmer" that is also updating an area of our repository by
pulling in changes from other repositories and applying them.
It isn't something I have tried to solve yet because I do not know if it
is a long term problem for me. But to return to my scenario suppose it is
decided that the EBCDIC port isn't worth polluting the trunk with, and I
couldn't get my own branch for it, then this is something I would want to
solve. Similarly, maybe we want to contribute the EBCDIC port but still
maintain our own custom private version with some specific hacks that
Subversion itself wouldn't want in the main tree. I could see the need
for something like this over the long term.
I think the main point is that it would probably be hard to do this with
Subversion as is, but your "history diff" idea could likely make it
doable.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 16 18:56:39 2004