Hi Ryan, On Thu, Apr 18, 2019 at 02:07 PM PDT, Ryan Schmidt wrote: > 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".
Agreed. And since it turns out disconnecting the history is not a big deal around here after all, I will probably simply use "svn import" instead of the complicated approach I was first considering. > 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.) The presumption that we currently have a single repository containing multiple projects is correct. And I very much appreciate your references to git and the fact that we need to think about what we're doing for the long-term. I can certainly see us moving to git at some point. > >>> 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. Thanks for this added detail. It pretty much matches what we are doing today regarding the checkout of a specific project. Thank you very much for the details and explanations! Best regards, -- Mun
