My first question I found the --private switch is not work for yard server, so how to make it work?
Second, I noticed that --private switch works for yard doc, if I choose to use the yard doc to generate doc files instead of using the yard server, How to make the rendering document have the frame (side bar)
Answering your second question: You can create a .yardopts file with --private and yard server will respect it.
One caveat is that after documentations is generated for a method, if you subsequently make it private you will need to delete the cache (rm -rf .yardoc) then restart yard server.
Related
I'm interested in using a session manager in emacs with the possibility of saving sessions by name.
The problem is that I almost exclusively use emacs to edit remote files. For this, I use tramp, which also works perfectly.
I want to have my sessions saved, including remote files and term buffers.
Does anyone know of a good way of saving sessions? I don't really care about windows sizes or splits
I have tried the following, which does not work:
Followed the instructions in this post, and tried out desktop.el. Searching and saving by name works perfectly.
Like this post recommends, I added this line so tramps are saved too:
(setq desktop-buffers-not-to-save "^$")
But, as I said, this does not work.
Ok, now it works. I'll post what I did, but I don't really know which was the problem.
Apparently, the line
(setq desktop-buffers-not-to-save "^$")
was not working. So I enter the customization interactively (M-x customize-gruop RET desktop RET, changed the value of Desktop Buffers Not To Save to none, reload .emacs, and it worked.
Is it possible to create branches in Perforce in a similar style to Git? I.e. without creating a new folder.
I would prefer for my client to manage the branches transparently whilst I work against a single copy of the directory tree on disk.
It seems awfully wasteful for the client to create an exact copy of the entire tree if you're only modifying say a couple of files. I much prefer Git's workflow in this regard.
If it's not possible using straight Perforce I'm happy to move to GitSwarm.
For info I'm running Perforce version 2015.1/1233444.
Possible yes, but with the centralized version of the system it involves a bit of 'magic'. Basically, the branch part doesn't need to involve the client at all anymore. Take a peek at p4 populate. That'll create another folder on the server, but won't do anything locally. Then you can edit your client workspace to map the branched files instead of the trunk files, and it'll just re-sync over top the files on your disk.
Now, having said that, if you wanted to take a look at our DVCS version of working, then you can just do "p4 switch -c " and it'll create a new branch locally, switch your workspace over to it (shelving any open current work in the process) and away you go.
My original answer was deleted because I thought a link was a better idea than repeating content. My mistake.
At any rate, I believe the DVCS features in Perforce Helix supply exactly the sort of thing you're after. In a blog I wrote in the subject (link here for reference) I explained how to create a new in-place branch with a single command:
p4 switch -c newBranchName
That will create a new branch with the name "newBranchName" and save any existing work in progress by default. To discover on which branch you're working you can use the switch command with the list argument as follows:
p4 switch -l
That would show you output like this, the asterisk showing that you're now working on the newBranchName branch.
newBranchName *
main
You can switch back and forth as you like, changing contexts as needed as often as you like. Your work in progress will continue to be saved on each branch in progress. When you're ready to merge your work back to main and push it back to the server, you can use the following sequence of commands:
p4 switch main
p4 merge --from newBranchName
p4 resolve –as
The first command switches back to the main branch, the second merges your work from the newly created branch into main, and the third resolves any potential conflicts automatically. If there are any conflicts that can't automatically be merged, then you can use the usual commands to walk through the resolution process.
Alternately, if you prefer to stick with Git, you can use that directly with our Helix Versioning Engine through our Git Fusion technology or use Git directly with our new GitSwarm technology. That is a pretty amazing option (in my opinion) as it makes it possible to mirror content automatically and bidirectionally between GitSwarm and the back end server. That way you get all the features of Git with GitSwarm (which itself is based on GitLab) and all the goodies from the rest of Helix.
Hope that helps!
If you use streams (Perforce's "managed" version of a branch, as opposed to doing completely ad hoc inter-file branching with arbitrary paths), it's pretty simple. As P4Gabe said, "switch -c" is a one-shot option on a local server.
On a shared server it's only a little more complicated because you have to do the "populate" explicitly (this is to keep naive users from accidentally branching lots of files lots of times on a shared server), but it's still only a few steps and it's something that you as an advanced user could script easily:
p4 stream -P (current stream) -t development (new stream name)
p4 populate -r -S (new stream name)
p4 switch (new stream name)
The equivalent is possible using ad hoc ("classic") branches as well if you have a good understanding of how client views work -- use populate to create the new branch, modify your client view to map the new branch into the namespace currently occupied by the old branch, and sync.
This blog post on what exactly "p4 switch" does might help if you're trying to engineer your own solution that's similar-to-but-not-quite the "switch" command: https://www.perforce.com/blog/150428/p4-switch-switching-it
I have a couple of Composite C1 CMS websites.
To edit them currently I use the web based CMS on the live site.
However - I would like to update the (code & content) in Visual Studio locally - then sync to the web. However, if my local copy is older than that online (e.g. a non techy client has edited something on the live site) and I Web Deploy - it will go over the top of the new file on the server.
I need a solution that works out the newest change? I can't find anything in Google or the C1 docs.
How can I sync - preferably using Web Deploy. Do I need some kind of version control?
Is there a best practice for this - editing the live site through the web interface seems a bit dicey & is slow.
The general answer to this type of scenario seems to be to use the Package Creator. With that you can develop locally, add the files you've changed to a package, and install that package on a live site. This solution does not at all cover all the parts of you question though, and has certain limitations:
You cannot selectively add content to a package. It's all pages or no pages.
Adding datatypes is easy, but updating them later requires you to delete the datatype (and data), and recreate the datatype.
In my experience packages works well for incremental site updates, if you limit the packages content to be front end stuff, like css, images and such.
You say you need a solution that works out the newest changes - I believe the only solution to this is yourself, with the aid of some tooling. I don't think there's a silver bullet solution here.
Should you use a version control system? Yes! By all means. Even if you are not sharing your code with anyone, a VCS is a great way to get to know Composite C1 from a file system perspective, as you can carefully track what files are changed on disk, as you develop. This knowledge is crucial when you want to continuously add features the a website that is already alive and kicking - you need to know what to deploy, and what not to touch.
Make sure you read the docs on how Composite fits in VCS: http://docs.composite.net/Configuration/C1-and-Version-Control
I assume that your sites are using the XML data storage (if you where using SQL Data Store, your content would not be overridden upon sync).
This means that your entire web application lives in one folder on disk on the web server, which can be an advantage here.
I'll try to outline a solution that could work for you, although I must stress that I've never tried this - I'm making it up as I type.
Let's say you're using git, download the site in it's entirety from the production web server, and commit the whole damned thing* to your master branch.
Then you create a new feature branch from that commit, and start making the changes you want to deploy later, and carefully commit your work as you go along, making sure you only commit the changes that are needed for your feature to work, to the feature branch.
Now, you are ready to deploy, and you switch back the master branch, and again download the entire site and commit it to master.
You then merge your feature branch into the master branch, and have git do all the hard work of stitching you changes in with the changes from the live site. There are bound to be merge conflicts, and that is where you will have to jump in, and decide for yourself what content needs to go live.
After this is done and tested, you can web deploy the site up to the production environment.
Changes to the live site might have occurred while you where merging, so consider closing the site, or parts of it, during this process.
If you are using SQL Data Store i suggest paying for a tool like Red Gate's SQL Compare and SQL Data Compare or SQL Delta, to compare your dev database to the production database, and hand pick SQL scripts that can be applied to the production database along with your feature deployment.
'* Do consider using a .gitignore file to avoid committing certain files - refer to the docs for mere info.
I suppose you should use the Package Creator
Also have a look here: http://docs.composite.net/Configuration/C1-and-Version-Control
I have two different version of a website, an older version, and a newer version that is supposed to have some sort of virus on it (or malicious code of some kind). I need to perform a diff between the two sites and try to eliminate the virus in the newer one.
After some searching I found netbeans 7.1 is able to do this using it's Git Repository. I was following this tutorial http://netbeans.org/kb/docs/ide/git.html but I am not getting the same options on my screen as in the tutorial. I am using netbeans 7.1 RC1 and downloaded the jdk from the link on that same page. The jdk download itself says jdk7 but the folder it creates on my computer is named jdk1.7.0_01 . I'm assuming jdk7 is short for jdk1.7 .
I get as far as the very end of the "Initializing a Git Repository" step. The end when it says "All the project files are marked Added in your Working Tree. To view a file status, place the cursor over the file name in the Projects window. The status of the file in the Working Tree displays in green to the right of the slash like shown in the following picture." does not happen.
I tried going further anyway, but there is just more and more options that do not show up for me.
I am also open to another way to perform a diff operation between the sites, it doesn't have to be with using netbeans. I should note however I do not have access to a unix box. So the solution has to work for windows, or I guess I can go on a coworkers mac if I need to.
Thank you.
From your question, it sounds like you did not already have your web site code under version control. If that's the case then I'd suggest doing so, and git is a very good choice. It is what I use.
Your goal, however, is to diff the older version of your site with the "newer" (possibly infected) version, and that can be done without having to deal with a version control system. There are several good diff tools for Windows. I mainly use WinMerge, as I like its user interface and simplicity. KDiff3 is another good one, and I use that one in conjunction with git merge operations, because it supports a three-way-merge comparison (which WinMerge does not).
If you were to use WinMerge for your diff, and you had the code from the old version in Q:\example.com\old-version and the "new" version in Q:\example.com\current-version, then you would start WinMerge, and either choose File|Open... from the menu, or click on the open icon in the toolbar. You would get a dialog like the following, and would fill it in as shown:
If you filled everything in correctly, then you would be able to click on the OK button, and would get a list of file differences. Depending on the default settings, you might also see files that have not changed at all in that list. You can hide those using the View menu. Double-clicking on a file with differences will open the two versions and show you the differences.
Explore the WinMerge options. I have mine set, for example, to compare white-space differences, but to ignore different line endings (Unix's LF versus Windows' CR/LF).
This is regarding my developmnent stage and the practice of testing all the JS before releasing it.
Unfortunatly we have some hardcoded references in our code. and this is the reason why there is no way for me to test a new version of test.js on the Stage server. and you only see the effects when it goes live.
Now, I know I should use relative paths etc.. but I was wondering if there is a Firefox plugin that could maybe substitute http://remote.site/test.js with /dev_path/to/test.js during pageload ?
I have also tried using hosts file for this purpose but it doesn't work in my scenario as I only need to map it to this 1 reference and not the whole domain.
Is there anything stopping you from changing the hard-coded references? That's really the easiest answer to your problem.
Run a find-and-replace on your files to replace the absolute links to relative ones. So long as the site hierarchy is the same for development and production, there shouldn't be any problems.