thank you for pointing that out. Well, we do have several large projects and if there are active branches that can't be finished out, it seems to me I could recreate them in SVN by checking in the project as it was before the branch was made, creating the branch inSVN, then replacing files that have since been modified in the new branch. Can you see any problems there? Thanks - D.
David On Mon, Apr 14, 2008 at 11:42 PM, Toby Johnson <[EMAIL PROTECTED]> wrote: > David Blaikie wrote: > > > Hi, I'm doing a much less ambitious "skim" (i.e., checking out code from > > VSS and adding directly to SVN) migration of our VSS repository. > > I think that in order to migrate active branches and labels from VSS, I > > should check out each branch separately and then add it directly to the > > branches directory in SVN. > > My approach would be this: > > > > 1. create a new project directory with branches/ tags/ and trunk/ > > directories > > 2. check out latest version of code from VSS > > 3. add checked-out tree into trunk/ in SVN > > 4. individually check out branches from VSS > > 5. add each as a separate branch in branches/ directory in SVN > > 6. individually check out labels from VSS > > 7. add each as a separate tag in tags/ directory in SVN > > > > does this sound correct? Would this allow developers to merge branches > > or tags with the trunk at a future point in time? > > > > Hello David, > > Unfortunately this approach will lead to a lot of wasted/duplicated space > in your repository. Ordinarily Subversion creates branches and tags using > its "cheap copies" so that only changes in a branch take up space. But if > you manually check these files in several times as suggested, you won't be > creating cheap copies but rather full duplicate copies of all files multiple > times. > > Whether that option is still desirable would be a judgment call on your > part; if your source tree isn't very large it may still be helpful but you > won't be able to perform the ordinary commands available with copied files > such as diff against the original and merging. > > So I'd probably recommend against that option and instead finish out any > existing branches using VSS then create new ones in SVN after you migrate. > > toby > > _______________________________________________ > vss2svn-users mailing list > Project homepage: > http://www.pumacode.org/projects/vss2svn/ > Subscribe/Unsubscribe/Admin: > > http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org > Mailing list web interface (with searchable archives): > http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user > > _______________________________________________ vss2svn-users mailing list Project homepage: http://www.pumacode.org/projects/vss2svn/ Subscribe/Unsubscribe/Admin: http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org Mailing list web interface (with searchable archives): http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
