I'm developing an MVC 2 application and have it on a web host. It works fine, but the strange thing is that when I update files, the updates don't "take". I can even delete an entire Controller file (just for testing the update problem), and it doesn't matter. I can still go to that page on the live site. That shouldn't be possible, but apparently it does, as if the Controller was still there.
The only way I can update the site at the moment is by deleting every single file on the server, and then upload the entire site again. Then (strangely) it works, and the updates take.
Does anyone have any experience with similar problems and ideas for how to solve it? BTW, I have asked the support at the web host, but unfortunately they rarely have any answers for anything but the simplest problems, so I thought I might be better off asking here.
If you edit a controller file, then you need to recompile it and deploy the .dll file, there is no need to even bother hosting the controller files.
You can edit the views freely though.
Related
I am new to Typo3. We have Test and Development Instances(CMS site) build through Typo3. We dont have problem in Development Instance but have in Test instance. The problem is, Whenever we change some content in pages from Backend, that content is not reflected in Frontend until 24hrs. Still now we did not find the solution. Please, if anyone of you know the solution, please share it. Thanks.
I have TYPO3 version 6.2 and there I have often problem that it is not enough to remove the cache due the backend and I have to remove cache manually.
That means to remove the content of typo3temp/cache/*. Then I can see the changes immediately. (I have to do that especially when I am changing translations).
Anyone out there using LiveCode in a multi developer project?
Either way, can someone recommend a good source control system / plugin to use?
We've looked at MagicCarpet but since it is no longer developed we wish to use something else.
Thanks
I'm working on a solution to this problem by exporting the stack file as a structured directory of script, json and image files which will diff and merge nicely in most VCS. It is not yet available but the intention is it will be open source. My goal is to demonstrate it at the RunRevLive conference in May.
Here's the repo for lcVCS https://github.com/montegoulding/lcVCS
I have put a git library stack on revOnline (libVersionControl) that exports to structured xml files that git can handle. It works as far as it goes, but I have hopes that Monte's solution will supersede this effort.
revOnline link to stack
Yes, our team has been using LiveCode with multiple developers. Since the Livecode community is still young, acquiring good source control tools can be a challenge. Our solution has been to break code into modules (stack files). When there are updates to merge into the main codebase, we clone our existing codebase, and merge code changes manually using line by line compare in a text editor. This is not a fun process, but is much less painful than it sounds.
If I were to redesign the system, we would simply use Git (Github.com etc.). There is no reason this would not work with Livecode stacks.
We use LiveCode in a small team with Subversion.
We don't have a perfect solution, but it is very lightweight; we all use a custom extension to the standard toolbar, which among other things has a 'save+backup' button. When we started using it with Subversion, we added code to this button which saves an XML sidecar file for the stack. The file contains all the scripts, custom properties, and optionally fields (controlled by user property in each stack). In our case almost all of our work is in scripts, so this works for us.
The effect is that each time we commit to SVN, we're always committing two files, the LiveCode stack and the accompanying sidecar file - the latter works fine for diffing etc.
Where this lets us down is that we don't have any solution for merging. If we were working on larger systems more actively, we'd also modify I expect look to modify the sidecar format into a complete folder of files. For now however this makes the situation workable (and it takes no noticeable time to generate the sidecar file).
Happy to share code if that was useful.
I know of a tool thats being worked on that is going to really help in this regard. When he showed it to me it looked very functional already. But I'm not sure when he will share it with the community.
So the point is, its just a matter of time before people's stuff comes together to make a turn key solution for this.
I wish to create a document repository for my company. Reason is because my company have many documents and they did not have a version tracking in place. This means everyone is using different version all the time.
Plone is something new to me and i got to know from a good friend of mine. And too bad he is not around anymore to answer my question. I believed in him and i wish to materialize his idea, to use Plone as a document repository for my company.
I have install Plone and manage to view the default Plone page, add all company's username and change the logo to my company's logo. And now the biggest question is, how to setup the document repository? What i have in mind was to create a "page" for the user to add files, download files, search for files and read its description.
Any lead for me to go about?
Reusable,
Same problem here. We started to use Plone as our main DMS 4 weeks ago (inserting existing docs at present).
For working copies, we use iterate (insert plone.app.iterate under eggs in your buildout.cfg).
For versioning, Products.CMFEditions. I believe this worked out of the box.
For creating new workflow, look into plone.app.workflowmanager and read the docs.
In a previous question we asked, we were still looking at Dexterity which has alot going for it but eventually we decided on adapting an existing content type based on Archetypes.
As for inserting files, as long as the description is ok, they will be found through the in-built search functionality, but you might consider using Iterate mentioned above to make sure that nobody is using the same file twice.
As your new, as I am, the docs seem hard at first but are actually quite good.
And this book is still giving me the foundation we need to keep adding functionality.
Good luck
I think, you should get pretty far with vanilla Plone installation, without developing your own extensions or other customization add-on-products. Therefore, I'd recommend you to start with Plone 4 User Manual to find out everything you could do out-of-the box.
As #Speediro mentioned, versioning support comes built-in for the main content types (and you don't actually see CMFEditions mentioned anywhere), but it's not activated for file uploads. Although, as briefly mentioned in the manual: Content items can be configured to have versioning enabled/disabled through the Site Setup → Plone Configuration panel under "Types".
Working Copy Support (plone.app.iterate) should also be there already waiting for activation on Site Setup's add-ons-panel.
Yet, before the Plone Collective (=community) Developer Docs or Professional Plone 4 Development, I'd recommend Practical Plone 3. It has a bit outdated graphics (because it was made for Plone 3), but it's great next step after the user manual. E.g. how to define content rules to send e-mails notifications for content updates (still through the browser without coding). Or how to create custom forms using Products.PloneFormGen.
When you really need to write your own code, it'd be time for Professional Plone 4 and the Collective Docs.
If you can't have a developer to manage your stuff, I would recommand to stay on official Plone, no custom code and use only widly used addons.
I mean:
stay on the default theme (sunburst)
use the default plone content types
only customize the logo
activate plone.app.iterate in the addon controlpanel
do not play with workflow because they need to know what you are doing. by default a file has the visibility of it's folder. It mean if you can see the folder you will be able to see all files inside. You can just activate default worklfow for files under the ZMI.
Use collective.quickupload addon
Your database will going really fast to a huge size because Plone is doing indexing and indexing means lot's of spaces. So you will have to handle this as system adminstrator;
I'm currently working on a project that's been going on for several years straight. The development-team is small (less than 5 programmers), and source-control is virtually non-existent, and the deployment-process as is is just based on manually moving files from one server to another. The project is in classic ASP, so building isn't an issue, as both deployment and testing is just about getting the files to where they need to be and directing the browser at the correct location. Currently all development is done on a network-drive which is also the test-server. The test-server is only available when inside the the local network (can be accessed trough vpn), and is available on the address 'site.test' in the browser (requires editing to the hosts-file on all the clients, but since there are so few of us that hasn't proven to be any problem at all). All development is done in visual studio. Whenever a file is change the developer that changed the file is required to write the file he changed into a word-document and include a small description as of what was changed and why. Then, whenever there's supposed to be a version-bump (deployment), our lead-developer goes trough the word-document and copies every file (file by file) that has changed over to the production-server. Now, I don't think I need to tell you that this method is very error prone (a developer might for instance forget to add that he changed some dependency, and that might cause problems when deployed), and there's a lot of work involved with deploying.
And here comes the main question. I've been asked by the lead developer to use some time and see if I can come up with a simple solution that can simplify and automate the "version-control" and the deployment. Now, the important thing is that it's as easy as posible to use for the developers. Two of the existing developers have worked with computers for a long time, and are pretty stuck up in their routines, so for instance changing it into something like git bash wouldn't work at all. Don't get me wrong, I love git, but the first time one of them got a merge-conflict they wouldn't know what to do at all. Also, it would be ideal to change to a more distributed development-process where the developers wouldn't need to be logged into vpn (or need internet at all) to develop, and the changes they made offline could be synced up when they were done with them. Now, I've looked at Teem Development Server from Microsoft because of it's strong integration with Visual Studio. As far as I've tested it seems possible to make Visual Studio prompt the user if they want to check in changes whenever the user closes Visual Studio. Now, using TFS for source-control would probably eliminate most of the problems with the development, but how about deployment? Not to mention versioning? As far as I've understood (I've only looked briefly at TFS), TFS has a running number for every check-in, but is it possible to tell TFS that this check-in should be version 2.0.1 of the system (for example), and then have it deploy it to the web-server? And another problem, the whole solution consists of about 10 directories with hundreds of files in, though the system itself (without images and such) is only 5 directories, and only these 5 should be deployed to the server, is this possible to automate?
I know there's a lot of questions here, but what is most important is that I want to automate the development process (not the coding, but the managing of the code), and the deployment process, and I want to make it as simple as possible to use. I don't care if the setup is a bit of work, cause I got enough time at hand to setup whatever system that fits our needs, but the other devs should not have to do a lot of setup. If all of the machines that should use the system needs to be setup once, that's no problem at all, cause I can do that, but there shouldn't bee any need to do config and setups as we go.
Now, do any of you have any suggestions to what systems to use/how to use them, in order to simplify the described processes above? I've worked with several types of scm-systems before (GIT, HG and SubVersion), but I don't have any experience with build-systems at all (if that is needed). Articles, and discussion on how to efficiently setup systems like this would be greatly appreciated. In advance, thanks.
This is pretty subjective territory, but I think you need to get some easy wins first. The developers who are "stuck up in there ways" are the main roadblock here. They are going to see change as disruptive and not worth it. You need to slowly and carefully go for the easy wins.
First, TFS is probably not going to be a good choice. It's expensive, heavy, and the source control in TFS is pretty lousy. Go for Subversion: it's easy to setup and easy to use, and it's free. Get that in place first, and get the devs using it. Much easier said than done.
Later (possibly much later), once the devs are using it and couldn't imagine life without a VCS, then you could switch to Hg or Git if you need first class branching and all those other nice features.
Once you have Subversion in place, you can use something like JetBrains TeamCity or Jenkins, both of which are free and easy to use. However, I'm just assuming you don't have a lot of tests and build scripts that the CI server is really going to be running, so it's far more important that you get VCS first. In all things: keep it as simple as possible. Baby steps. Get some wins, build trust, repeat.
I can't even begin to think where to begin with this! Intending no offense directed at you, apart from the mention of git and HG, this post could have been written 10 years ago.
1) Source control - How can a team of developers possibly work effectively without some form of source control? Hell, even if it's Visual Source Safe (* shudder *) at least it would be something. You have to insist that the team implement source control. You know what's available so I won't get into preaching about that. (However, Subversion with TortoiseSVN has worked quite well for me.)
2)
"write the file he changed into a
word-document and include a small
description as of what was changed and
why"
You have got to be kidding... What happens if two developers change the same file? Does the lead then have to manually merge two changes that s/he extracts from the word doc? Please see #1 and explain to them how commit comments work.
Since your don't really need to "build" (i.e. compiled, etc.) anything, you should be able to solve most of your problems with some simple tools. First and foremost you need to use a source control solution. Yes, the developers would have to learn how to use another tool (EEEK!). You could do the initial leg work of getting the code into the repository. If you have file access to the other developers machines, you could even copy a checked-out working copy to their machines so they wouldn't have to do the checkout themselves (not really that hard). You could then use all the creamy goodness of version control to create version branches when each deployment needs to be done. You could write simple scripts using the command line SVN tools to check out said branches and automatically copy the files to the target server(s). Using a tool like BeyondCompare, the copy process could be restricted to only the files that are different (plus BC can handle an FTP target if that is an issue). By enforcing commit comments on the SVN repo, you'll guarantee that the developers provide comments, and for each set of changes between releases you could very easily generate a list of all those comments using the CSM log retrieval features.
I'm developing a web app.
If I include a jQuery plugin (or the jQuery file itself), this has to be put under my static directory, which is under SCM, to be served correctly.
Should I gitignore it, or add it, even if I don't plan on modifying anything from it?
And what about binary files (graphic resources) that might come with it?
Thanks in advance for any advice!
My view is that everything you need for your application to run correctly needs to be managed. This includes third-party code.
If you don't put it under SCM, how is it going to get deployed correctly on your production systems? If you have other ways of ensuring that, that's fine, but otherwise you run the risk that successful deployment is a matter of people remembering to do all the right things, rather than some automated low-risk "push the button" procedure.
If you don't manage it under SCM or something similar, how do you ensure that the versions you develop against and test against are the same? And that they're the same as production? Debugging an issue caused by a version difference you don't notice can be horrible.
I generally add external resources to my project directly. Doing so facilitates deployment and ensures that if someone changes the version of this file in your project, you have a clear audit history of what happened in case it causes issues in the code that you've written. Developers should know not to modify these external resources.
You could use something like git submodules, I suppose, but I haven't felt that this is worth the hassle in the past.
Binary files from external sources can be checked in to the project as well, although if they're extremely large you may want to consider a different approach.
There aren't a lot of reasons not to put external resources like jQuery into your repo:
If you pull it down from jQuery every time you check out or deploy, you have less control over which version you're using. This holds true for most third-party libraries; you probably don't want to upgrade your libraries without testing with your code to see if it breaks something.
You'll always have a complete copy of your site when you check out your repository and you won't need to go seeking resources that may have become unavailable.
For small (in terms of filesize) things like jQuery and images, I'd just add them unless you're really, really concerned about space.
It depends.
These arguments relate to having a copy of the library on your system and not pulling it from it's original location.
Arguments in favour:
It will ensure that everything needed for your project can be found in one place when someone else joins your development team. I've lost count of the number of times I've had to scramble around looking for the right versions of libraries in order to be able to get something working.
If you make any modifications to the library you can make these changes to the source controlled version so when a new version comes out you use the source control's merging tools to ensure your edits don't go missing.
Arguments against:
It could mean everyone has a copy of the library locally - unless you map the 3rd party tools to a central server.
Deploying could be problematical - again unless you map the 3rd party tools to a central server and don't include them in the deploy script.