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

RE: multiple "svn import" behavior

From: Jay Freeman \(saurik\) <saurik_at_saurik.com>
Date: 2002-01-11 20:30:13 CET

Yes. This was one of the complex behaviors I was concerned about a
while back when I wrote "Scome Scenarios I'm Interested In / Concerned
About" to this list back at the end of November (which I don't think
anyone read, hehe). My main usage of CVS isn't on my own code but is on
other peoples' code (mostly nmap from Fyodor).

He releases a new version as a tarball, I get it, CVS import it into my
repository, check out the head with a -j merge between the two vender
revisions, resolve conflicts, and commit. Wash, rinse, repeat. I
maintain a rather annoyingly integrated patch, and doing it all manually
rather than letting the version control do it is unacceptable.

Also, this _is_ "import" conceptually. If I start with a few releases
of a program that I haven't had in version control yet (possibly because
I'm waiting for Subversion to solve some of my real problems as well as
CVS has, such as the ability to have symbolic links in content so
multiple repositories share the same directories... also in my Scenarios
post), and I want to "import" those multiple revisions as a new
repository (or even into an existing one...), I would expect to use
"import".

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

-----Original Message-----
From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
Sent: Friday, January 11, 2002 11:18 AM
To: Ben Collins-Sussman
Cc: boissier@media.mit.edu; dev@subversion.tigris.org
Subject: Re: multiple "svn import" behavior

Ben Collins-Sussman <sussman@collab.net> writes:
> If you choose to write the feature, it shouldn't be part of 'svn
> import'. We're trying to resemble CVS behavior to some degree.
> Perhaps I would call it something like 'svn overwrite'.

I haven't been following this in detail, but isn't the desired feature
basically like CVS's vendor branches? This is something we'll need to
think about, though *after* we get the `merging' side of branching and
merging done. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:56 2006

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.