Re: Importing from a working copy ... bad idea?

On Apr 18, 2019, at 15:40, Mun Johl wrote:

> On Thu, Apr 18, 2019 at 01:30 PM PDT, Ryan Schmidt wrote:
>>
>> On Apr 18, 2019, at 14:04, Mun Johl wrote:

>>> Since many files will be renamed
>>> and/or moved to different relative locations, the svn log for those
>>> files would not be maintained anyway (I don't think) by svnmucc.
>>
>> Why wouldn't it preserve the history? Preserving history is the whole point.
>
> I "thought" (perhaps incorrectly) that if I copied a file out of an
> existing ws dir and into a new non-ws directory; then later did an
> 'svnmucc put' of that file that SVN may treat the file as a new addition
> to the repo--since the file had never been checked into that particular
> location before. Is that not the case?

Oh. Yes, certainly, in that case, you have disconnected the history, by using a non-Subversion command to copy the file out of the working copy in the first place. But if you use svnmucc to copy a file from one URL in a repository to another URL in that same repository, its history will be preserved. If you're only using svnmucc to "put" a bunch of individual files, that's no better than (and much more complicated than) just using "svn import".

In this whole thread we are presuming that you have a single repository containing multiple projects. In that case, you can preserve history. But another approach is to use a separate repository for each project, and if you're going to do that, you won't be preserving any history. While Subversion users freely use both approaches, it's worth seriously considering the single-project-per-repository approach, since that's what's used in git. Subversion allows you the freedom to decide where to put your trunk/branches/tags directories -- either at the top level, or underneath directories for each project, or any other arbitrary layout you want. Git does not allow you that freedom. You may not want to use git today, but maybe you will want to convert your repository to git eventually, and if so, it will be easier to convert single-project Subversion repositories than it will be to write a complicated set of svn2git rules to split multiple-project repositories. (We did it successfully with the MacPorts Subversion
repository a couple years ago, but it was difficult.)

>>> I was thinking I would do all of the manipulation via linux commands and
>>> get the structure the way I wanted
>>
>> What I haven't understood in this thread is why you think that's easier than using the corresponding Subversion commands.
>>
>> For example, if you were planning on using "mkdir", "cp" and "mv" to arrange your new project, why can't you use "svn mkdir", "svn cp" and "svn mv" instead, and then once you're happy with it "svn commit" it?
>
> You make a good point. Maybe I'm just more comfortable in the linux
> world and not as well versed with SVN.

The only difficult part would be getting a single working copy that contains all of the files that you want to copy. If your repository is arranged like this:

/projectA
        /trunk
        /branches
        /tags
/projectB
        /trunk
        /branches
        /tags

and you want to make a new project trunk and copy files from projectA's trunk and projectB's trunk into it, you probably don't want to also check out all of the branches and tags of each project. You could start by checking out only the top-level directories:

svn checkout https://url/to/repository --depth immediates wc
cd wc

Then you could update the trunks of the projects you want to copy files from:

svn update projectA/trunk projectB/trunk

Make a directory for your new project:

svn mkdir --parents newproject/trunk

You can "svn mkdir" any other directories you need in your new project's trunk, and you can "svn cp" files into it from the other projects as needed, and finally "svn commit" the whole thing.
Received on 2019-04-18 23:08:17 CEST