We use VSS. I had tried to move to subversion, but my plan was shot down from on high. I know VSS inside and out, and with that understanding I decided that trying to move stuff around inside VSS to the maven structure wouldn't be worth it. I created a new source safe database and started fresh.
Now, to be fair, our source layout is pretty complex, and the changes I made to move to maven were significant, so any source control system would've been put through its paces to handle it properly. If you aren't in VSS now, and you have a choice, I can't stress enough how much better subversion will be for you. Every day I pull my hair out knowing how much easier everything would be if I had been allowed to replace VSS. I actually had the new SVN tree set up and running, and had to then import that into VSS. Grrr. I've used vss2svn recently, as I'm still pushing to move to subversion, and I wanted to see if I could move the recently created VSS db to subverion. It works pretty good, but I only did this on a main trunk. I don't think it could create branches effectively in subversion, but to be fair, source safe treats them differently, so it would be quite a difficult task. Also, the person working on that project scrapped it and is trying to rewrite from scratch. The last version is available. Its perl, but there's a statically linked exe version available. Back to VSS. If you have an existing source tree, you can move stuff around to preserve history. However, you need to be careful. VSS is highly flakey in this regard. I'd suggest doing a full branch (share with "Branch after share" checked) of your code first, and move that around. Then when done, just make that the main branch. This will keep your history around. Personally I have a habit of migrating to new VSS db's every few years because they get nasty. I've found in practice that leaving the old db around for history lookups is generally good enough. Again, go with subversion if possible. As to directory structure, I'd suggest moving your code to look like maven's recommended layout. If only for clarity. It took me a little while to "get it" with regards to maven, but once I was there I was happy. The developers in my group are currently dealing with the rampup of moving to a new layout and build scheme. There have been some initial grumblings, but I think its about the same. Once they start to "get it", its good. On 3/23/06, Christophe DENEUX <[EMAIL PROTECTED]> wrote: > > > > I your project is not under SCM today, you can directly move directories > before to commit under your SCM: CVS, SVN or VSS. > > If you want to import your project into VSS before to move directories, > verify if VSS can keep history during moving. > > > FYI: You can use vss2svn to migrate from VSS to SVN. I have never use it. > > > > Christophe > > raja bangaru a écrit : > > But i'm intended to use VSS > > > > Will it be fine? > > > > On 3/23/06, Christophe DENEUX <[EMAIL PROTECTED]> wrote: > > > >> Raja, > >> > >> I think that the maven directory structure is better. > >> But, if you use CVS as SCM, you must migrate to SVN before to move your > >> directories, otherwise you will loose the CVS history. Use cvs2svn to > >> migrate from CVS to SVN, it works fine. > >> > >> > >> Christophe > >> > >> raja bangaru a écrit : > >> > >>> My project which is build in ant does'nt use maven standard directory > >>> structure > >>> > >>> src/main/java-------- java source files > >>> src/test/java --------- java test files > >>> > >>> Now i want to migrate to maven > >>> > >>> Which way of directory structure is bettter????? > >>> > >>> moving my files to the above directory structure? > >>> OR > >>> change my POM ? > >>> > >>> Help me pls > >>> > >>> > >>> > >> This message contains information that may be privileged or > confidential > >> and is the property of the Capgemini Group. It is intended only for the > >> person to whom it is addressed. If you are not the intended > recipient, you > >> are not authorized to read, print, retain, copy, > disseminate, distribute, > >> or use this message or any part thereof. If you receive this message > in > >> error, please notify the sender immediately and delete all copies of > this > >> message. > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > This message contains information that may be privileged or confidential > and is the property of the Capgemini Group. It is intended only for the > person to whom it is addressed. If you are not the intended recipient, you > are not authorized to read, print, retain, copy, disseminate, distribute, > or use this message or any part thereof. If you receive this message in > error, please notify the sender immediately and delete all copies of this > message. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
