On Thu, Oct 13, 2011 at 12:39:55AM +0200, David Paleino wrote: > (no need to CC me, I never unsubscribed from debian-med@, eh :))
:-) > > I was advised by Alioth admins to do so and they installed all > > preconditions to run the tools that are creating the tasks pages. > > Uhm, ok. > I knew about the symlink just yesterday -- there are people using this > method for other projects (Ansgar Burchardt for PET, for example), so I > thought > it was the "accepted way" of doing things. Well, for PET only purpose this method is probably perfectly OK. But we are doing more stuff than only PET - thus we experience this conflict. > Could you expand this point? > What does this "publish" target do? Does it scp things from vasks to wagner? See http://anonscm.debian.org/viewvc/blends/blends/trunk/blends/doc/Makefile?view=markup IMHO this manual triggering of publishing something has some advantages because it enables you to commit some intermediate status which is not automatically subject for publishing. I personally would prefer this anyway so I do not really see a constraint in the fact that postcommit hooks do not work any more. > I'm not entirely sure that's the most correct way. Those are the same admins > we > made the symlink wagner:/srv/home pointing to vasks :) > > Anyway, we can contact them, asking for clarification. However, I would like to get the tasks pages working *before* we have sorted out this. So I would love to revert your change right now (risking that postcommit hooks will not work for the moment - PET should keep on working if you copy the code manually ... at least I think so). > > No problem. I do see two ways to get things working again: > > > > 1. Revert the general symlink for htdocs and symlink only to those > > files / directories which really profit from this step. > > 18 symlinks seem too much to me :) > > dapal@wagner:~/debian-med/htdocs$ ls |wc -l > 19 > > (-1 → tasks/ directory, which wouldn't be symlinked) Even if it is actually 17 (-1 for bugs/) I agree that this is hardly a good idea because when creating a new file this will break. > > 2. Revert the symlink and use a publish target as I suggested (and > > do not use the postcommit hook to move things around > > This is what I did not understand :) Please see the Makefile linked above. Currently your workflow is like 1. Changing something 2. svn commit --> changes are populated My proposed workflow is: 1. Changing something 2. svn commit (NOTHING will be populated) 3. make publish --> changes are populated While this is actually one step more I *really* think that this one more step is reasonable. Thinking once more before publishing is IMHO a sane thing to do and I was actually never really happy about the shorter workflow. I'm somehow tempted to revert the symling soonish because I need working tasks pages (nowish) because I need to demonstrate something here. For the moment nothing should be broken by this change back because the working code is just populated, right? BTW, did you created a copy of the old htdocs dir before creating the symlink? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
