I am having hard time understanding Read the Docs version control for my documentation (may be because of lack my understanding!).
All my project documents are hosted on GitHub and I am trying to setup versions for my document that needs to be in-sync with the latest development releases.
How to manage these doc versions/what are the configurations in sphinx config?
Is there a way I can time travel my document. i.e., If I want to see
any older version of my doc, how can I (re)publish this on Read the
Docs?
Currently, what I am doing:
For a particular development release cycle (say rc1.2), I communicate with the engineers for the changes and I make those changes to my doc; merge the feature PR to main branch. On merging, Read the Doc builds a latest version (latest is pointing to main).
How to see the changes for rc1.0, rc1.1. I am thinking of creating something like change_log.rst and list the changes for each releases. But this would be something only for reference. How to manage these in Read the docs on admin/GitHub?
Related
Is there a way to do this easily? Keep version history of the document on the document? As a .gdoc or .whatever-format or am I resigned in having to download, separately, all the revisions made in the past on said document?
For context: I have a document I've been editing and revising over the years for my own medical history and list of meds, history, etc. etc. and have been using Google Docs to do this, because it was convenient and I didn't have to pay for Microsoft Office and additionally install a good word processor on my PC. Now recently I've purchased Dropbox Personal for cloud storage needs.
I want to do the following: Take the Google Doc and save it as a .gdoc (which isn't an option in the File menu??) and take it over to Dropbox's Vault as an editable hardcopy with its revisions history in tact.
Otherwise, what I have done (before I even comprehended revision history was a thing) is just copy pasted its current version, onto a new .gdoc in Dropbox Vault.
So, is that possible? And if so, how and as easily (lazily) as I possibly can? Also, is this even the right place to ask for this? Apologies if it isn't. I didn't see much else about this specific issue anywhere... (also lazy)
Thanks!
EDIT:
I am by no means a coder in any sense. I'm a full time elderly caretaker and I'm just a guy with a specific, niche?, technical, problem and thought this was the first place to ask without having to go through tech support w/ Google chat etc. And it might also help some other people that like seeing how their documents have changed over the years, history fans etc. At the end of the day it's a programming/coding issue, that could be resolved someway some how... Right?
If I can add pictures here for context, LMK.
Thanks :)
The .gdoc file format is only accessible via Google Docs which is on web. Downloading the file to your local storage means you would have to access it on your device using your local apps (word editor) such as Microsoft Office,Libre Office, etc.(other word editor apps on desktop application level) which is why the .gdoc format is not available when you download. This is also why you won't be able to have it openable from your dropbox.
The version/revision history on Google Docs is intact only to that specific file with that unique ID. So when you download the file, the version history won't be available to the physically downloaded file which is stored on web or even when you make a copy of it, the version history does not get copied, therefore that won't be an option too.
It looks like you'll have to stick to manually copying or making a backup of the current version of the file before editing, since the version history is only kept for a period of 30 days or the last 100 versions, unless manually set to "Keep forever" to keep a version forever.
Google drive version history: https://googledrivepro.com/google-drive-version-history/
I have required feature A.feature and optional feature B.feature, latter has plugin B.plugin. I want to move B.plugin to under A.feature.
Similar question has been asked before, but solution requires keeping B.feature as dummy feature for people upgrading, because installing new version of it is required for those who had the plugin installed before, however for new users it's unnecessary noise in update site.
So I tried using patches - currently have set up:
B.plugin - empty, dummy plugin with id as before, will be used in patch
B.patch.feature - includes the dummy B.plugin
A.plugin - copy of old, non-dummy B.plugin with new id
A.feature - includes B.patch.feature, marked as optional, and A.plugin
This seems to work perfectly if B.feature was installed before, but if it's not, then during installing the new version of A.feature the install process it says
B.patch.feature is not applicable to the current configuration and
will not be installed.
and forces user to uncheck B.patch.feature before proceeding.
Is there a way to get it to work or is there another approach to take, ultimate goal being having B.plugin under A.feature in way that B.feature will no longer be seen in update site? Having A.plugin and non-dummy B.plugin active
at the same time causes errors.
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'm trying to configure a trac server we are using in my team, in order to avoid an undesired behaviour. We are mainly developing free and open-source software in the team, but we sometimes need to be able to build our early prototypes as completely private.
Because of our first constraint, we want our timeline to be visible for anonymous users. But because of the seconde constraints, we want some commits to be completely hidden from the external world, i.e. we don't want anybody else than us to be able to read the message and content of some commits in the timeline.
Unfortunately, I've been unable to configure Trac the proper way to reach this behaviour untli now. I wan't find a configuration that would let me manage the Timeline content with enough accuracy.
Consequently, I would like to know if such a configuration is possible with trac.
For information, I'm using Trac 0.12.2. The installed plugins are :
Trac 0.12.2
TracAccountManager 0.2.1dev-r7731
TracNav 4.1
The only permission I can see that is related to Timeline is TIMELINE_VIEW.
EDIT :
I have forgot to mention something. We don't want to loose the private commits. And we want them to display for registered users. Consequently, it's not a solution for us to remove them from the database.
EDIT 2 :
Ideally, we would like the commits' message to be displayed according to the right to read the content of our Subversion repository. The idea is that, if a commit is made on a part someone can't access, this person is not supposed to be able to read the message of the commit either.
EDIT 3 :
If we have a look in the configuration file of trac, we already can find :
permission_policies = AuthzSourcePolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy
and the authz_file variable is properly set too. Moreover, svn access to the private folders of the svn repositories can't be accessed by anonymous users.
You should set up authz checking for both your Subversion repository and your Trac installation. You can use the same permission file for both. For Subversion, see Path-based authorization in the SVN book. For Trac, enable and configure the trac.versioncontrol.svn_authz.AuthzSourcePolicy component.
This will allow you to have a very fine-grained control over who can access which part of the repository. Note that the implementation of AuthzSourcePolicy in Trac 0.12.2 has a few bugs that will be fixed in 0.12.3.
There are two ways of going about this :
1) You can directly edit the plugins that are running in trac, and add a module that helps you to filter these out at the code level (i.e. you can edit the behavior of the script to , say, only include commits which exclude certain key words). The timeline script is here (trac 2.4) : /usr/local/lib/python2.4/site-packages/trac/Timeline.py (here is an online diff snapshot of the source code : http://trac.edgewall.org/attachment/ticket/890/Timeline.py.diff)
2) You can remove the commits entirely - trac commits are derived from the sqlLite database (the schema is here http://trac.edgewall.org/wiki/TracDev/DatabaseSchema).
Of course, there also might be some fancy tools out there that provide a nice interface for editing the way the timeline looks.
Finally - temporarily, you can remove the timeline/roadmap entirely from the trac.ini file : http://www.gossamer-threads.com/lists/trac/users/28079
I confess that I've virtually no experience with the repository part of Trac, even less with using a repository with a variety of permissions across it's contents.
On the subject: Configuration is certainly not enough, see rblanks answer. While I've never seen the code for that functionality, I was wrong to suggest it doesn't exist. Because it is a central place and developed/supported in Trac core this is definitely the way to go.
I would like to get an automated changelog from Trac, that will include references to tickets that made some important changes to the architecture/design of the code. My ideal scenario would look like this:
According to some ticket I make a change to SVN
I add some specific line to the ticket saying that this changeset created an important change to the code/wiki
I go to some dedicated Trac page and see a full list of such changes made with the project.
In other words, it's going to be a changelog, which is available for all project participants, and the entire team will be updated about the important changes with source code and wiki.
Can you suggest any Trac plugin for this? Or maybe Trac itself can do it?
ps. Would be excellent to have another "Plans Log", where everybody can post their plans on future changes. Again, inside tickets.
Have you tried the ChangeLogMacro on TrackHacks: http://trac-hacks.org/wiki/ChangeLogMacro
Sample:
[7280] by doki_pen on 12/18/09 20:27:15
Update body reference to output.
Since body isn't defined. Fixes #5538
[7191] by doki_pen on 11/26/09
02:18:32
watch user feature
fixes #3546
[7190] by doki_pen on 11/26/09
02:18:21
copy changes
trying to make things more intuitive
for users
Personally I'm looking for something a little more like the VirtualBox changelog which I can then put into a plain text file. So if anyone knows how to do this I'm interested!
www.virtualbox.org/wiki/Changelog
Sample:
VirtualBox 3.1.2 (released 2009-12-17)
This is a maintenance release. The following items were fixed and/or added:
VMM: fixed SMP stability regression
USB: fixed USB related host crashes on 64 bits Windows hosts (#5237)
Main: wrong default HWVirtExExclusive value for new VMs (bug #5664)
Main: DVD passthrough setting was lost (bug #5681)
VBoxManage: iSCSI disks do not support adding a comment (bug #4460)
VBoxManage: added missing --cpus and --memory options to OVF --import
VirtualBox 3.1.0 (released 2009-11-30)
This version is a major update. The following major new features were added:
* Teleportation (aka live migration); migrate a live VM session from one host to another (see the manual for more information)
* ...