Thank you for the concise and detailed pitfals warning. This time we were not expecting anyone working already with SVN in terms of modifying the code. So we appologize for the inconvenince and lack of warning.
In the future we will be issuing a warning to the forum in advance about moving the folders and other such changes. As with other complicated and possibly dangerous changes, we want to be educated and conscious about the approach. It is understandable, that once the structure of categories and addons is stable, and addons are used in production, it would be extremely difficult to make changes of names and locations (will require deprecation over a J release at least). So, at this inception and migration stages it is ever so important to get the categories and addon names right to ensure long life of uninterrupted naming and location. When such change of name happens, it will be required to re-pull the affected SVN folders locally and delete the old folders. To ensure minimal local sychronization effort, it is recommended to keep the local contents up to date by committing changes frequently. There is a mechanism in the build system to trigger a build only when the code is ready, which allows to keep any intermediate changes in SVN without producing an unfinished addon distributable. --- [EMAIL PROTECTED] wrote: > To quote http://www.jsoftware.com/jwiki/Subversion/User_Guide : > > Let me emphasize one point: using subversion means that you will > NEVER lose any committed files or changes to those files. > > ... unless someone decides to rename a directory in the tree, > as just happend for example with the switch from addons/excel/tara > to addons/tables/tara. > > Dear tree maintainers (Chris,Oleg,Alex): Please don't do this lightly. > While the SVN people brag about being able to rename files/dirs, this > it not really true. An "svn move" is a mere copy followed by a delete. > (Ref: http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.move.html ) > > If you do such a thing, locally modified files do _not_ migrate along > with the rest to the new name. SVN checks out the official repository > version to the new name, and the user has to reconciliate all local > changes manually. This can be a tedious affair. > > What's worse: it is very easy to miss this happen at all and to build > the next version missing the local changes. If it weren't for the Wiki's > RSS feed listing a related "fix links" change by Chris, I wouldn't have > noticed what (not) happened. > > My "svn update" today resulted in roughly 50 lines of output quickly > scrolling by. SVN did not particularly warn about uncommitted changes > in a "D"eleted file, it just let the concerned file silently linger around. > It takes some revision control experience to do the right thing > in this situation. For example, you cannot even do a naive "svn diff" > at this moment to see what your local change were. > > I happen to have enough SVN background knowledge to resolve this quite > quickly (10 minutes), but others might not be so lucky. Furthermore, > the additional work accumulates along with every locally modified file. > > So my plea: > > - Please avoid renamings/relocations in the SVN tree if possible. > > - If you absolutely cannot resist a name change, please > post an announcement to the "programming" mailing list > giving an explicit Heads up! to all SVN users. > > I know that it's difficult to predict a taxonomy suited for future > developments, but IMHO mere aesthetics alone do not justify a renaming > with the impact as described above. In the specific case of "table/tara" > vs. "excel/tara" I'm even unable to see any advantage of the new > nomenclature. Am I missing something? > > Martin > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
