I've installed the latest AjaxControlToolkit and everything's working fine and dandy.
When I go to check-in my changes none of the ACT stuff is ticked for check-in but any pages I have edited have been ticked.
Is there a specific reason for this? Should I not check it in?
Possibly some quirk of your source control provider.
Personally, I like to include everything (non-standard) required to build the solution in SVN.
For AjaxControlToolkit, I use Nuget.exe, packages.config containing a line relating to a specific version of AjaxControlToolkit, and a pre-build event to automate downloading the correct version of the toolkit just before the build.
This way, you get to tie a specific revision of your work in source control to a specific version of the toolkit, without having to check binaries in to source control (bad practice).
Related
Whenever we clone a site on a development machine, the PackageStates.php will be rewritten shortly after and the order of entries will be all over the place, resulting in tons of changes, even though nothing has actually changed logically.
This brings up the question, should the file actually be under version control?
We experimented with ignoring it, but then, when deploying on a new machine, the site will not know which extensions to load. Which suggests to me that it shouldn't be excluded from version control. But then how should the information, which extensions to load, be transferred?
You can include the PackageStates.php to your version control.
You also can exclude it from versioning and generate it automatically during deployment process. typo3-console has a command for this:
typo3cms install:generatepackagestates
In older TYPO3 versions < 9 LTS, you have the option to install extensions based on conditions like context, host, system you can use
$GLOBALS['TYPO3_CONF_VARS']['EXT']['runtimeActivatedPackages'] = array('extension_builder','devlog');
in your AdditionalConfiguration.php.
Article about this topic at typo3blogger.de
If you have a TYPO3 composer installation, PackageStates.php is automatically generated when running "composer install":
https://docs.typo3.org/p/helhum/typo3-console/6.5/en-us/CommandReference/InstallGeneratepackagestates.html
Generates and writes typo3conf/PackageStates.php file. Goal is to not have this file in version control, but generate it on composer install.
We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?
I have a small team of web developers who work together on up to 50 external sites. I am trying to find a better solution to using Dreamweaver's check-in check-out for managing source. We have just started using Visual Studio 2012 here and there and I am curious if TFS is the way to go for us. No one here has ever used versioning or any type of source control before, so I am looking for something similar to what they are used to.
If it matters at all, our sites are all hosted on a Windows 2008 R2 server, and largely written in C#.
I think TFS is a good option to consider. As several people have commented, it will be a jump from what you are your team are used to in Dreamweaver, but I personally feel if you are serious about managing your intellectual property, you will invest in some sort of version control system. With that said, there will be a learning curve regardless whether you are your team select TFS, SVN, Git, etc.
Assuming you do go with TFS, you do get the added benefit of everything else that comes with TFS - it's not just about version control. This includes work item tracking, automated builds/deployments, reports, a simple SharePoint site, etc.
With TFS you get the benefit of all of these features, combined into a single product. You can accomplish a similar setup using open source products as well, but would require you to piece the products together.
I'd use the integrated Subversion client in Dreamweaver, which does the basic stuff very nicely and doesn't require the tedious navigation process that will lead to your team bypassing the system. Only problem, DW does not support the latest versions of SVN so you need to pick up an SVN server that is compatible. Try this:
Setting Up Version Control for Dreamweaver CS6 on Windows
Any previous attempts to get version control working may well have created some .svn folders and files on your PC. You MUST remove ALL of these and UNINSTALL ALL OTHER VARIETIES of Subversion software from your PC before you start.
Go to the VisualSVN Server website and download an archived standard version of their software, version 2.1.16 . Don’t be tempted to grab a later version, because this will install SVN 1.7 or 1.8 and neither will work with Dreamweaver.
http://www.visualsvn.com/server/changes/
Trying to get DW working direct to a local folder using the file:// protocol probably won’t work and is also known to put data at risk. You need the server. I chose to install the VisualSVN server with the default settings, other than opting to use Windows logins and go with HTTP, not HTTPS. I decided to have the repositories live on an internal SSD drive, but any local drive will do. When creating a folder for your repositories to live in, use a name that is pretty general e.g. ourcorepositories . I used lower case for everything.
Right click on ‘Repositories’ to create a new one. Give it a name without any spaces or special characters e.g. mynewprojectrepo and check to ‘Create default structure’ . Before you OK, note the Repository URL and copy it into Notepad or a similar plain text editor so you can refer to it later during 6 below. It will be something like
http://OFFICEDESKTOP/svn/mynewprojectrepo
Notice that the capitalised part of the URL is the name of your computer. Click OK and you now have a repository for your project.
5. Boot DW and go to your project. If you don’t have a project yet, create one and stick some dummy files and folders in it. Go to Site menu>>Manage sites… and 2-click your project. Select Version Control.
6. Set Access to be ‘Subversion’ (no other choices exist), Protocol to be HTTP and for the Server Address enter the name of your computer in lower case e.g.
officedesktop
For the Repository Path enter (e.g., using current example from 4. Above)
/svn/mynewprojectrepo
The Server Port should be 80 . For the Username enter your Windows user name, in lower case. Enter your Windows password for the Password. This is the name and password combo that you use to log in to your PC . Click the Test button and you should get a success message. If not, the best advice is to delete any .svn files and repositories you have created and start again. Be sure not to add any slashes or omit any; the above works. Before you click Save, click the link to the Adobe Subversion resources and bookmark it in your browser. There is a lot of useful background information there. Click Save, click Done.
7. Go to your DW project and open up Local View. All of your site’s files and folders will have a green + sign beside the icon. Right-click on the site folder and click ‘Version control>>Commit” . It is a very good idea to leave comments whenever you change anything, so leave a Commit Message along the lines of “The initial commit for My New Project” and click to Commit. If you have a lot of files to go to the repository, they’ll take some time to upload. As they upload, the green + signs disappear to show that you local version is in synch with the repo.
8. Okay, that’s it, you have Version Control in Dreamweaver CS6. It may also work in CS5 and 5.5. Check out those Adobe resources for some good insights on workflow. I can’t help with any other ways to implement version control, but I can maybe save you time by saying that DW doesn’t integrate with Git and that the basic, but integrated, Subversion client in Dreamweaver is way better than having no version control. For coverage against physical disaster, I’d also add in a scheduled daily backup of your entire repositories folder to some cloud storage.
Apologies for any errors. I’d recheck all of the steps, but A) I think they’ll get you up and running and B) it’s easier to do the install and set up the first time than the second time (all those .svn files and folders to get rid of).
I am setting up a project that will be shared among several programmers at my organization. We are using git--to which I am a newcomer. The project directory includes symbolic links to documentation directories that should not be under version control. I want to maintain the symlinks under version control as symlinks, rather than having them dereferenced and all of the content of the symlinked directory placed under version control.
I find that the git command line tool behave the way I want: git add -A. However if I try to use the Eclipse version of git, eGit, to add all the currently unversioned files, using Team->Track on the project context menu, eGit wants to add every file in the symlinked directories. Is there a way to tell eGit that, no, these are really symlinks, and should not be dereferenced?
Our problem was discussed in this: Eclipse Community Forums Thread
It looks like currently the Linux native lstat support is not too easy to make portable. The Least Common Denominator paradigm that they have for programming Eclipse in Java make it harder to do Linux or Mac native stuff. (read: *cough* Windows doesn't support symlinks *cough*).
The good news is:
It seems possible, but they'd need to code it in a way that complies to their 'Write Once Test Everywhere' programming standards. I feel that it's important to have some native stat and lstat support on Linux when using EGit because of this problem, as well as Eclipse bug #346079.
Simply having EGit installed causes slowdowns & IDE freezes when doing a Git Refresh :-(
The bad news is:
These two bugs are stopping me from using EGit for the majority of my git commands. The user experience makes EGit unusable for me. It would be really nice to be able to use EGit within Eclipse so that Mylyn User Stories & Tasks could be tied to feature branches automatically. It would also be great to have the automatic commit message template features. This would make putting the current task & status in the commit message a breeze.
This is bugging me almost enough that I'm ready to see if it's possible to make some scripts to query Eclipse / Mylyn for the current commit message template output, and do the git commit from the commandline using this. I'm not sure how automatic per-user-story feature branch creation would work though.
Until these problems get fixed, I'm sure a lot of EGit users will not be happy :-(
We suffered from this problem cluttering up the commit screen no end, and occasionally causing someone to forget to include a file they had created.
The solution we came up with was to manually edit the .gitignore files to include the paths where the linked files would appear when the symlinks were dereferenced:
/ProjectHomeFolder/.gitignore
Since we were working in the Play Framework we also edited the following ignores:
/ProjectHomeFolder/conf/.gitignore
/ProjectHomeFolder/public/.gitignore
We simply added
/ModuleName for each of the modules that were symlinked and now egit ignores them properly, for completeness here is the full contents of my root .gitignore file, that sits in the root directory of the project:
/.project
/.classpath
/.gitignore
/eclipse
/tmp
/crud
/.git
/.settings
/modules
/conf
/betterlogs-1.0
/chronostamp-0.1
/logisimayml-1.5
/betterlogs-1.0
/sass-1.1
/deadbolt-1.4.2
/jquery-1.0
/log4play-0.5
/messages-1.1.1
/navigation-0.1
/jqueryui-1.0
/scaffold-0.1
/table-1.2
/tabularasa-0.2
After doing a fresh checkout using Subversive, some of the directories retrieved because of svn:external properties are showing up as obstructed. However not all of them are. A command-line use of "svn status" properly shows all the directories as externals with no obstructions.
Why is this happening?
This does looks like this thread
We checked the situation and we had found that the problem can happen in case if working copy is locked by external process in time of update.
For example, the process TSVNCache that related to TortoiseSVN time-to-time produces conflicts with working copy access and JavaSVN library cannot complete working copy modification in correct way. As result working copy goes into "Obstructed" state, i.e. it is damaged.
The same diagnosis related to any process which locks working copy in time of working copy meta-data modification. (We found same behavior for MS Visual Studio 2005 Express Edition, but I don't know why the Studio locks WC?)
So be sure to make the checkout with the least possible number of application running.
Another source of conflict could be:
The SVN 1.4.x-compatible clients are automatically converts working copy into 1.4.x-compatible format. At the current moment Subversive Default client is incompatible with SVN 1.4.x working copy format.
So, if you performed any modification of the working copy using command line SVN client in your case you will get "Obstructed" state indicated over the resources in the workspace tree.
In order to resolve the problem I will propose you to switch SVN client option and select SVN Kit 1.1.0-based client or Native JavaHL 1.4.2 client.
Next, if resources already decorated as "Obstructed", please close and then open again corresponding projects or simply restart Eclipse IDE in order to reload SVN meta-information cache.
Now : the exact version may not be the same for you, but that is another lead to check.