immitev Posted December 14, 2011 Report Share Posted December 14, 2011 We would like to tranistion from SourceSafe to PlasticSCM. Currently we have two issues: 1) There is VSS Importer availabel on for PlasticSCM 3.x, right? Do you plan to have a SourceSafe importer for PlasticSCM 4? Any other options? 2) In VSS one could have different working folders for some subprojects of a VSS project (e.g. f1\s1 -> c:\s1 and f1\s2 -> c:\temp\s2). Couldn't find such feature in PlasticSCM... What are the recommended workarounds (e.g. separate repositories or workspaces? Link to comment Share on other sites More sharing options...
manu Posted December 14, 2011 Report Share Posted December 14, 2011 Hello immitev, 1) In PlasticSCM 4.0 we are focused on the fast-export/fast-import capabilities which is the commmon language between modern VCS. Since VSS is a little bit old system there is no native fast-export feature. But I can provide you with some links to tools that are able to fast-export VSS repositories into SVN, and although SVN is also an old dinosaur it has fast-export capabilities. http://www.poweradmi...vssmigrate.aspx http://www.polarion....s/svn/index.php http://vss2svn.codeplex.com/ 2) We always recommend to have one repository per project and if they are related projects you can use our xlinks to manage them, take a look to this blogpost: http://codicesoftwar...ing-xlinks.html Manu. Link to comment Share on other sites More sharing options...
immitev Posted January 30, 2012 Author Report Share Posted January 30, 2012 Thanks, 1) The fast-export + fast-import worked well for us 2) For our challenge with "different working folders", we are thinking of using NTFS junctions as a workaround to be able to work with a single repository. We did some limited testing and it seems it works well, but I wonder if you have tried such an approach (and if there are some risks involved)? Link to comment Share on other sites More sharing options...
manu Posted January 30, 2012 Report Share Posted January 30, 2012 1) The fast-export + fast-import worked well for us Cool! can you tell us which approach did you use? 2) For our challenge with "different working folders", we are thinking of using NTFS junctions as a workaround to be able to work with a single repository. We did some limited testing and it seems it works well, but I wonder if you have tried such an approach (and if there are some risks involved)? I assume your junction tests were out of PlasticSCM, right? I'm saying this due to the junctions support is not ready yet. Manu. Link to comment Share on other sites More sharing options...
immitev Posted January 30, 2012 Author Report Share Posted January 30, 2012 1) We did VSS -> Plastic3 -> Plastic4 migration 2) We just tried using NTFS junctions in a client machine. E.g. for a junction [c:\workspace\folderA\ -> c:\folderB\] when we added or modified a file in c:\folderB\ the PlasticSCM client correctly picked up the changes. Is this a good enough tests? What else is to be implemented for a junction support? Link to comment Share on other sites More sharing options...
manu Posted January 30, 2012 Report Share Posted January 30, 2012 2) We just tried using NTFS junctions in a client machine. E.g. for a junction [c:\workspace\folderA\ -> c:\folderB\] when we added or modified a file in c:\folderB\ the PlasticSCM client correctly picked up the changes. Is this a good enough tests? What else is to be implemented for a junction support? Basically we need to implement the support for junctions inside the workspace, scm operations over junctions an so on. More or lees the same operations you can do with unix symlinks. Link to comment Share on other sites More sharing options...
immitev Posted January 31, 2012 Author Report Share Posted January 31, 2012 Basically we need to implement the support for junctions inside the workspace, scm operations over junctions an so on. More or lees the same operations you can do with unix symlinks. Could you elaborate on that... Which operations do not work properly on a workspace with junctions? And is official support for junctions in a workspace planned? Link to comment Share on other sites More sharing options...
manu Posted January 31, 2012 Report Share Posted January 31, 2012 Hello immitev, officially the junctions are not supported. Link to comment Share on other sites More sharing options...
manu Posted January 31, 2012 Report Share Posted January 31, 2012 Hello Ivan, I read your mail, I'm going to try to explain better what is supported and what is not. What plastic can do: You have the following workspace: "c:\Dev\MyWorkspace" Inside it you have the directory "c:\Dev\MyWorkspace\MyDir", which is a junction to "c:\MyDir", created by yourself. You can work with the junction transparently, add files into "c:\MyDir" -> they will appear on "c:\Dev\MyWorkspace\MyDir", modify files, co, ci and so on. No problems here. What plastic can't do: Plastic is not able to create the junctions by its own. The junction must be created by the user to enjoy the junction capabilities. If the junction is not created plastic will create the "MyDir" directory as a regular folder and inside ii all the content that was added: Z:\MyDev\MyWorkspace\MyDir\dirContents.... Regards, Manu. Link to comment Share on other sites More sharing options...
immitev Posted January 31, 2012 Author Report Share Posted January 31, 2012 Thanks, that's much better (I suspected there is some inherent problem with junctions support), but for us it's OK to handle them with PlasticSCM assistance. Link to comment Share on other sites More sharing options...
manu Posted February 1, 2012 Report Share Posted February 1, 2012 I'm sorry about my first answer, I didn't understand the scenario completely , I finally understood it with your mail! Ok! Feel free to ask us if you have any questions. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.