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

RE: Subversion vendor branch revisited...

From: Doyle, Patrick <WPD_at_dtccom.com>
Date: 2006-02-02 15:39:25 CET

> From: Ph. Marek [mailto:philipp.marek@bmlv.gv.at]
> Sent: Thursday, February 02, 2006 9:24 AM
> To: users@subversion.tigris.org
> Cc: Doyle, Patrick
> Subject: Re: Subversion vendor branch revisited...
>
>
> On Thursday 02 February 2006 15:21, Doyle, Patrick wrote:
> > I had a bizarre thought yesterday and thought I would pass
> > it on to the list for comments...
> ...
> > Suppose I modified Subversion such that the name of the
> > ".svn" directory was specified by an environment variable
> > (such as SVN_META_DIR) instead of being hard coded in the
> > client code. Then I could do things like:
> ...
>
> As I don't really know the implications of these changes, eg.
> importing the .svn in one repository, the .svn.vendor in the
> other, with corresponding problems when updating one to an
> older version (trashing the information of the other
> repository), etc....

My thinking was that my (standard) svn would treat the .svn.vendor
directories just like any other directories. Not much different than making
a tarball of the vendor distribution when I get it and placing it on a CD,
just for safekeeping. In this case, the "just for safekeeping" part would
be in my subversion repository.

>
> I'd suggest using svk - it should do what you need, ie.
> mirror a remote repository, ease working on local branches,
> and supports generating patches.
>
Of course, if somebody else has already solved my problem for me, then I'll
go use that instead :-) Thanks for the tip... I'll check it out.

--wpd

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 2 15:42:30 2006

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

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