[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Thoughts and open questions on patch/dump unification

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-09-16 18:05:42 CEST

cmpilato@localhost.localdomain wrote on 09/16/2004 11:50:34 AM:

> Mark Phippard <MarkP@softlanding.com> writes:
> > I started to write a similar reply as I was also thinking of this as
> > a patch you would apply to a WC then you would just resolve
> > conflicts and commit as normal. However, I then recalled Eric did
> > mention previously that he saw this as a way of synching
> > repositories.
> Hm.
> 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.

Let me pose a scenario to you, part real, part hypothetical. I will
confess that I have not looked for a way to solve this yet, so it may be
doable already with what Subversion offers.

We are working on porting Subversion to OS/400, which is EBCDIC based
(which I mention because that is where the majority of the work lies). The
port is a fairly substantial amount of work over a fairly substantial
amount of time. We have our WC attached to the Subversion repository and
the 1.1.x branch so that we can keep synched up with changes. Eventually,
we obviously want to be able to submit this back as a patch.

We have not had to do anything with TortoiseSVN or Subclipse, and are not
likely to, but lets just say we did to complicate it a bit more as they
are in different repositories.

Ideally, we could have our own Subversion repository that mirrored trunk
or branches from these repositories. We could then make branches within
our repository for our port and use regular Subversion features to update
our branch from the main branch as it is updated with the master
repository, as well as commit from our WC.

We work on Windows so svk is not an option. How could we do something
like this? It sounds like this new proposal would be able to solve
problems like this.

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.



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:06:10 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.