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.
