Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: Using version control software with Stata


From   William Buchanan <[email protected]>
To   [email protected]
Subject   Re: st: Using version control software with Stata
Date   Fri, 28 Mar 2014 07:54:23 -0500

I think Nick raises a very interesting strategy with regards to the -strL- variable capacity in Stata 13.  If you use the Stata dataset like this, if you regularly commit your programs to the dataset you can use -datasignature- and/or -checksum- as one method of ensuring that all changes are tracked/logged in some type of a permanent medium.  The project manager in Stata 13 is definitely something that is extremely helpful for organizing things and creating a single, clean, and easily navigable workspace to work; I've not had any experience with Robert Picard's -project- (SSC) program, but from the Statalist traffic that it already generated it seems like it'd also be worthy of checking out.  If you primarily work on a Windows box, you can run multiple instances of Stata simultaneously, otherwise it'd be tricky figuring out how to switch back and forth.  

One other thing to consider, potentially, is whether or not you need to do your programming collaboratively.  If you're the only person doing the coding, then you have much more freedom in choosing a tool that meets your explicit needs and preferences.  However, if your work needs to be part of a larger team's work then an external VCS may be useful/necessary.  For example, although you can store your program files on a shared/networked/cloud drive, reconciling simultaneous edits to the files or even allowing multiple people to work on the same files simultaneously can be arduous.  Take MS SharePoint as an example.  Although several people can simultaneously read the files, it isn't always the friendliest when it comes to simultaneous editing (others may have had other experiences, but I've typically run into the only one person can have write permissions at a time issue).  Other platforms allow simultaneous edits which can be reconciled and reversed much more easily (e.g., !
 you can typically revert back to a previous commit in a VCS fairly easily).  

If you are working on a Windows machine - primarily - maybe looking into building a dataset and storing the files as -strL- variables would be something worth looking into since it wouldn't require you to gain any additional fluency with other programs.  It also seems like it could be an extremely easy/flexible way to maneuver things as well (especially if you take some time to familiarize yourself with some of the tools in the data management sphere of commands).

HTH,
Billy
On Mar 28, 2014, at 7:05 AM, Nick Cox <[email protected]> wrote:

> Records of programs means quite different things to different people,
> but similar (or similar-sounding) questions could interest many
> people, so different ideas may be worth noting.
> 
> I should mention Stata 13's project manager and Robert Picard's
> -project- (SSC), which might help.
> 
> I've never used version control software. The problem as I face it is
> not really different versions -- except by accident, when I am working
> on different machines, or careless about which directory I am working
> in, or about which superseded versions still exist, where I am much
> less tidy and systematic than many other people are.
> 
> The problem is I face it is just keeping track of programs I have
> written. That usually means programs defined by ado-files, but the
> issues could be very similar for do-files.
> 
> I've played over the years with two very simple Stata-based ideas.
> 
> One is  Stata datasets in which each program or do-file is a single
> observation. Clearly you have the whole of Stata to use there and can
> record dates, grouping by projects, extra notes, etc.
> 
> In Stata 13 up, I guess that you could hold programs themselves using
> -strL- variables, although I've not tried it.
> 
> It can be a little tricky to look at that and work with some other
> dataset, so you need two Statas open, which is the main disadvantage.
> 
> The other solution is to have a help file documenting programs or
> do-files. This doesn't have to be SMCL-based, as -view- can be used to
> look at any text file that might be relevant here, but SMCL allows
> clickable links to help files, to run files, etc. and that can be
> mighty useful. What I do for my commands in the public domain can be
> seen in -njc_stuff- (SSC), but it's no more than that what works for
> me, and either simpler or more complicated solutions might be needed.
> 
> A development of a point just made is that a substantial project can
> itself be documented by its own help file. Nothing says that help
> files are just what programmers write to document (more or less
> substantial) commands. Anyone with a text editor can write a help file
> and use it purely privately if they so wish.
> 
> Nick
> [email protected]
> 
> 
> On 28 March 2014 10:26, Maarten Buis <[email protected]> wrote:
>> I have thought about it many years ago, but never done it. What works
>> for me is to work with directories. So for a program -simpplot- I have
>> a directory called "simpplot", and within that I have directories
>> called "1.0.0", "1.1.0", "1.2.0", etc. Whenever I want to change my
>> program I create a new directory with the new version number, copy the
>> latest version in it, and start working.
>> 
>> I make heavy use of the trick that when you -clear all- and then -cd-
>> to a directory with an .ado file in it, that .ado file will be loaded,
>> even if you installed another version (e.g. from SSC). The same is
>> true for the help files. So when working on a new version of
>> -simpplot- I want Stata to load that new version (and fail horribly,
>> so I can debug it...), so I -cd- to that directory. When I am working
>> on another project and want to use -simpplot- I typically want to use
>> the "official" version (the one from SSC), which is fortunately still
>> the default with this way of working.
>> 
>> This works for me because each of my programs are failry
>> self-contained and consist of only a small number of files (-hangroot-
>> is probably an exception).
>> 
>> Best,
>> Maarten
>> 
>> 
>> On Fri, Mar 28, 2014 at 6:23 AM, Timothy Mak <[email protected]> wrote:
>>> Hi Statalist,
>>> 
>>> I'm beginning to accumulate quite a lot of different do files and ado for the projects I'm working on, and am thinking of using a version control software to help me keep records of my programs. However, I don't have a computer programming background, and therefore no experience of using these things, and am not even sure it's something that's useful for do and ado files. However, if anyone on the list has experience to share in this regards, I'd very much love to hear.
> 
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/faqs/resources/statalist-faq/
> *   http://www.ats.ucla.edu/stat/stata/


*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index