> Okay, I've created skeletal issue #599 for this, annotate it if you
> get a chance, otherwise I'll write up a description after this
> milestone is done.
>
> -Kar
>
> > Jay, can you (possibly with Guillaume and anyone else who wants to
> > contribute) describe the desired behavior precisely in a new issue?
> > That way at least we know we won't forget to do it. :-)
Karl, Jay,
I have added the description below to issue #599.
Comments, suggestions, criticisms welcome!
Cheers,
-- Guillaume
Here is the use cases I am interested in for a better "svn import". Jay,
others, please feel free to add to this. I'd like to point out that what I
am describing is _not_ the same as CVS's vendor branches, even though it
shares similarities.
USE CASES
------------------------------------------------
Description of use case #1
A user desires to move an existing project to Subversion while keeping
source code change history. Whether or not the project was under revision
control previously is irrelevant, but what is important is that in this use
case, the only thing available to the user are snapshots archives of the
project (for example one tarball for each archived version together with a
text changelog).
A good example of this would be the Linux kernel project, for which there
exists archives versions since v0.0.2 on the kernel ftp site, together with
a changelog.
Main requirements for use case #1:
- Ability to populate a new Subversion repository with history from prior
development, including changelogs and release tags, thereby catching up to
the latest existing version of the project.
- Must be extremely easy to do for the user, i.e. it must not require manual
merge, resolving conflicts or checkouts to a local repository. In short, it
must be easy to automate through the most simple of scripts.
- Since it is a one time task that will usually be done through a script
looping through the zipped archives, efficiency is not very important. The
script can be run once at night. It is more important to make this
straightforward to the user than to go to great lengths to minimize the
network traffic between the user's computer and the repository.
- Once the repository is populated, the developers should be able to start
working on the project right away, to make diffs with prior revisions, get
the changelog history, checkout any previous releases as they were tagged,
etc. as if the project had always been managed using Subversion and if "svn
commit" had been used to create each new revision.
------------------------------------------------
Description of use case #2
Same as use case #1 but here the repository already exists and contains
revisions in it. The archive we are trying to import into the repository is
just one library or subproject previously managed somewhere else and that
fits into a single directory somewhere.
------------------------------------------------
Description of use case #3
Same as use case #1 but here we also want to be able to create branches in
the repository for some archived versions to mimic what happened during
previous development.
Again, to use the example of the Linux kernel project, we want to be able to
tell Subversion to branch out the 2.4 kernels (stable) and the 2.5 kernels
(development).
------------------------------------------------
Description of use case #4
A user manages a Subversion repository for his project and needs to include
a library that is developed in parallel somewhere else using some other
revision control tool. Again, the one thing available to the user are
tarballs of each successive version of the library.
The library goes into one specific directory of the user's repository, and
what he would like to do is update this directory inside the repository
regurarly without merging anything by hand, having to resolve conflicts,
etc.
PROPOSED BEHAVIOR AND SYNTAX
All these use cases are just multiple facets of the same problem: the
ability to replace (or add) a directory in the Subversion repository by any
directory on the user's machine. Whatever was in the directory prior to the
import will be replaced by the content of the imported directory, modified
files will be updated, new files will be added, non existing files will be
removed. If the directory did not exist prior to the import, it is created.
There is _no_ branching happening here, just creation of a new revision.
It is also expected that any svn diff, or other operation between any 2
revisions would produce the same result as if the code had been commit using
"svn commit" instead of "svn import". Also, I am proposing there are no
vendor tags like in CVS, just release tags.
My preferred approach would be to modify "svn import", since as Jay
rightfully pointed out, this really _is_ import conceptually. If it is
absolutely crucial to stick with CVS syntax, Ben's suggestion of "svn
overwrite" is good also.
Use case #1 syntax
------------------
$ cd archive
$ tar xfz myproject-v1.0.tar.gz
$ cd ..
$ svnadmin create myproject
$ svn import -m "Changelog for v1.0 ..." -tag version-1.0 file:///myproject
archive/myproject-v1.0 topdir
$ svn import -m "Changelog for v1.1 ..." -tag version-1.1 file:///myproject
archive/myproject-v1.1 topdir
$ svn import -m "Changelog for v1.2 ..." -tag version-1.2 file:///myproject
archive/myproject-v1.2 topdir
...
Use case #2 syntax
------------------
$ tar xfz netlib-v3.3.tar.gz
$ svn import -m "Update netlib to v3.3" file:///myproject netlib-v3.3
topdir/lib/netlib
Use case #3 syntax
------------------
$ tar xfz linux-2.4.15.tar.gz
$ mv linux linux-2.4.15
$ svn import -F Changelog-2.4.15 file:///linux-kernel linux-2.4.15 linux
$ svn tag -b dev-2.5 (versions 2.4.15 and 2.5.0 are the same
except the version #)
$ tar xfz linux-2.5.1.tar.gz
$ mv linux linux-2.5.1
$ svn import -F Changelog-2.5.1 -j dev-2.5 file:///linux-kernel linux-2.5.1
linux
Use case #4 syntax
------------------
$ tar xfz netlib-v3.3.tar.gz
$ svn import -m "Update netlib to v3.3" file:///myproject netlib-v3.3
topdir/lib/netlib
<several weeks and multiple revisions later, a new version of netlib is
available...>
$ tar xfz netlib-v3.4.tar.gz
$ svn import -m "Update netlib to v3.4" file:///myproject netlib-v3.4
topdir/lib/netlib
---------------------------------------------------------------------
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