I'm trying to add an xlsm file to one of the markdown files in my repository, and that repository is published as wiki. What I want to do is that I want to have the xlsm file to be downloadable from the markdown file when click on it. This works perfectly fine for file formats such as docx, pdf and xlsx, but when I add an xlsm file as a link, it gets blocked. The link is highlighted as red and when I click on it, it goes to a not-found page instead of downloading it.
It looks like this is implemented by Microsoft as a sort of a security precaution for macro-enabled excel files, but is there a way to bypass this?
A rather poor workaround is to name your files with another, fictitious file extension, e.g. MyFile.xlsm.xlsx or MyFile.xlsm.txt. Then you can provide instructions to your users to download/save them with the fictitious extension removed, e.g. MyFile.xlsm. From a security perspective, this is not an advisable practice.
I cannot find official documentation stating which files are or are not supported. However, it's reasonable to assume you are correct. The .xlsm files are likely blocked for security reasons.
I document my software using the README.org file, which is rendered nicely in the master branch in GitHub. Now, suppose I create a tag v1.0 and want to share a link to that tagged version with others. Unfortunately, when one follows that link, he does not find my README.org nicely rendered, but only the archived code. So, what is the correct way of documenting a tagged version at GitHub? (of course, I am looking to re-use my README.org).
I'm using Perforce version control system (http://www.perforce.com/) and would like to format source code files (mainly XML) when developers submit their files to Perforce. I know that Git and SVN allow script hooks that provide for that.
Is there a way to change files that are being submitted to Perforce using some kind of a hook?
How can I do that on Perforce?
Thanks!
When I've done these sorts of policy-enforcement tools in the past, I've done it post-commit.
That is, after the submit completes, my tool retrieves the newly-submitted files, re-formats them according to the policy that I'm enforcing, and submits the re-formatted files as a follow-on change.
I do this by writing a tool that monitors changes similarly to the way the change review daemon monitors changes, so that the tool notices new submits and reviews the new files to see if they comply to the organization policy.
I generally have the tool perform a "revert -a" prior to the submit, so that if the files were formatted according to policy by the original developer, no second submission occurs.
I actually think this is a better approach than trying to do it during the submit:
The change that is submitted is exactly as the user provided it, with the identical content as provided by the user
The modifications that are due to the tool are clearly visible in a separate submission, which makes it very easy to recognize when the tool has gone astray and damaged the file during its re-formatting (such tool bugs do occur).
The net effect, overall, is the desired one: the files at the head of the branch are formatted according to company policy.
A Perforce trigger is what you need.
[[Please note that Github has changed a lot since this question was first asked; instead of "download page" read "new release".]]
I generate PDF documentation as part of my projects and I'd like them to stay in sync with my Git repository (it's not always possible for people to build their own since they often use proprietary fonts).
However, it's not really "correct" to add the PDFs to the repository since it's a derived file; furthermore, doing this adds significantly to the size of the commits and the size of the repository overall.
Is it possible to programmatically send files to the GitHub download page? (I know that tagged commits are automatically added there with git push --tags but I don't know where this is documented. I suppose I could do something fancy by adding a separate branch only containing the PDFs themselves — as done by the GitHub user pages — but I'm a bit rusty on using Git this way.)
Github API v3 supports this feature.
GitHub also provides a maven plugin based on the java API that is part of the Eclipse Mylyn connector for GitHub.
There is a ruby gem called github_api.
The other answer talks about net-github-upload which is available for perl and ruby.
check out for net-github-upload which is available
for perl: http://github.com/typester/net-github-upload-perl
and ruby: http://github.com/Constellation/ruby-net-github-upload
With that you can write a small script to upload and update your PDF easily. To sad there's no easy way provided by github guys themselves..
cheer!
The GitHub blog post announcing that this feature has been disabled: https://github.com/blog/1302-goodbye-uploads
I take it that by "GitHub download page", the owner means a repo–more specifically a branch– that can be downloaded via the "download" button.
If you want to add a file to a repo using the API, you will have to become familiar with the process described here: https://developer.github.com/v3/git/
It's not the easiest process in the world, but mastering it will force you to understand the concepts of blobs, trees, commits and references, amongst others.
You can't just "send a file" to a repo because you're working with Git, and Git has some "internal expectations" that you just can't ignore (it's impossible to think of GitHub as some sort of host that you can ftp). Explaining the flow required to create a file in a GitHub repo is certainly beyond the scope of the original question, but to provide a clear answer: no, it's not possible to programmatically upload a file on GitHub, but yes it is possible to programmatically push a file on GitHub".
There's a PHP library named GitHubTreePHP that lets you automate the process (Disclaimer: I wrote it).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am in charge of about 100+ documents (word document, not source code) that needs revision by different people in my department. Currently all the documents are in a shared folder where they will retrieve, revise and save back into the folder.
What I am doing now is looking up the "date modified" in the shared folder, opened up recent modified documents and use the "Track Change" function in MS Word to apply the changes. I find this a bit tedious.
So will it be better and easier if I commit this in a version control database?
Basically I want to keep different version of a file.
What have I learn from answers:
Use Time Machine to save different
version (or Shadow copy in Vista)
There is a difference between text
and binary documents when you use
version control app. (I didn't know
that)
Diff won't work on binary files
A notification system (ie email) for revision is great
Google Docs revision feature.
Update :
I played around with Google Docs revision feature and feel that it is almost right for me. Just a bit annoyed with the too frequent versioning (autosaving).
But what feels right for me doesn't mean it feels right for my dept. Will they be okay with saving all these documents with Google?
I've worked with Word documents in SVN. With TortoiseSVN, you can easily diff Word documents (between working copy and repository, or between two repository revisions). It's really slick and definitely recommended.
The other thing to do if you're using Word documents in SVN is to add the svn:needs-lock property to the Word documents. This will prevent two people from trying to edit the same document at the same time, since unfortunately there's no good way to merge Word documents.
With the above two things, handling revision controlled Word documents is at least tolerable. It certainly beats the alternative of using a shared folder and track-changes.
What on Earth are you all Word-is-binary-so-no-diff people talking about? TortoiseSVN, for example, integrates right out of the box with Word and enables you to use Word's built-in diff and merge functionality. It works just fine.
I have worked on projects that store documents in version control. It has worked out pretty well, although if people are unfamiliar with version control, they are probably going to have conceptual difficulties with things like "working copy" and "merge" and "conflict". Don't overestimate the users' capabilities when you plan your document management system.
I believe there exist big and powerful commercial solutions for all of this, as well. I'm sure if you have enough kilodollars, you can get something that fits your needs perfectly. Document management systems are a big business for big enterprise.
I guess one thing that nobody seems to have asked is if you have a legal requirement to store history of changes to the doc's?
Whether you do or don't is going to have an impact on what solutions you can consider.
Also a notification mechanism for out of date copies is also a bundle of fun. If engineer A has a copy of a document and engineer B then edits it and commits the changes you want engineer A to be notified that his copy is out of date.
Document control can become a real can of worms quite easily.
Maybe keep the doc's under CVS or SVN and set it up so that emails are generated to whoever has checked out a copy when updates for the same doc. are checked in to the repository?
Edit: I forgot to add don't forget to use the binary switch, e.g. -kb for CVS, when adding the new doc. Otherwise, you will get any sequences of data that happen to match the ascii for keyword strings having the relevant config management data appended thereby corrupting your doc. data.
Thinking out of the box, would migrating to a Wiki be out of the question?
Since you consider it feasible to force your users into Subversion (or something similar), a larger change seem acceptable.
Another migration target could be to use some kind of structured XML document format (DocBook comes to mind). This would enable you to indeed use diffs and source control, while getting all sorts of document formats for free.
Sharepoint also does a good (ok decent) job of versioning MS-specific documents.
How about trying git , It seems git can support word .doc and open document .odf files if you configure it in .gitattributes file.
Here is a reference , Scroll down to diffing binary files .
For what it's worth, there is also Google Docs. I guess it's not a perfect fit, but it's versioning is very convenient.
Clearcase integrates with Word for revision tracking. I believe Telelogic DOORs does as well.
I use Mercurial with the TortoiseHg overlay. I can right-click a changeset, choose "Visual Diff", then choose the "docdiff" tool (comes bundled), which launches the document in Word with the Track Changes.
You can, but you will allways compare the document versions with Word itself.
I haven't heard a version control database which can track changes in Word documents.
However there are some tools which can compare Word documents, so if you set up your version control client to use these tools for comparison, you can have some fun.
Not necessarily. It depends on how often the new files are committed to the repo. If the files are edited several times before a commit, then you're precisely where you are now. The biggest benefit is if the file becomes corrupted.
You can version any file; this is how Time Machine in Mac OS X Leopard works, for example, and there is an interesting article by someone who committed his entire computing environment into CVS and then just maintained working copies on his home and work machines.
But "better" and "easier" are specific to your situation, and I'm not sure I completely understand your problem as things stand.
Subversion, CVS and all other source control systems are not good for Word documents and other office files (such as Excel spread sheets), since the files themselves are stored in a binary format. That means that you can never go back and annotate (or blame, or whatever you want to call it), or do diffs between documents.
There are revision control systems for Word documents out there, unfortunately I do not know any good ones. We use such control systems for Excel at my work, and unfortunately they all cost money.
The good thing is that they make life a lot easier, especially if you ever have to do an audit or due diligence.
If you use WinMerge it has added support for merging Word and Excel binary files.
Have a look at Sharepoint. If cost is an issue, Sharepoint portal sevices can also work for you. Read this for more info
You could use something like the Revisionator, which is like google docs but with built in revision control including diffs, forks, and 3 way merges. http://revisionator.com
UPDATE: It also fixes the problem of too frequent autosaving that you mention with Google Docs. It'll still autosave to prevent data loss, but it will only create a new version in the revision history and share with other users when you explicitly "release" your changes.
Just wanted to clarify an answer someone gave but I don't have enough points yet.
diff will work on binary files but it is only going to say something not really useful like "toto1 and toto2 binary files differ".
You could do that, but if that files are binary you should always put a lock on it before editing. You won't get a conflict (which would be unresolvable).
Many of the new version control projects are better suited to entire directories, and not so much for single files.
Convincing someone that they need to get an entire project, when they only want to update an individual file can be a "fun" way to spend an afternoon.
Another option you have is a piece of software and cloud computing magic called dropbox. Or, you could ditch the word documents and make a locally shared mediawiki instead.
DropBox:
getdropbox DOT com
MediaWiki:
mediawiki DOT org
YES, it's applicable! I totally agree to say that the combo SVN+TortoiseSVN suits well to track MS Office documents. You can lock a document for edition, write protect all unlocked files to avoid conflicts (i.e. parallel modifications), diff two versions of the same file, see the history of all the modifications and of course rollback to an older revision.
I tried to describe all of those tips in a dedicated blog post. (disclaimer: I'm the blog owner)
All of this could even be accessible from the web with a SVN web client! (might need some software development)
But if you're not accustomed to Version Control Systems in an other context this may not be the obvious choice. The needed work for a good integration with docs give dedicated tools an advantage: "electronic document management" systems are made just for that. A VCS like SVN may stay a good alternative for cost reasons :-)
Did you test the online service Simul? It looks promising, I personally like the GitHub-like orientation. Note that I'm not affiliated to Simul!