How should I version control (sort of) unrelated scripts in the same path?
I’ve started using version control to better manage revisions to my PowerShell code. I decided to use Mercurial for 3 main reasons:
- As a DVCS, it doesn’t require a server.
- If I want to, I can store a private repository online for free (bitbucket.org)
- It seemed simpler to use than Git.
Mercurial works well for versioning PowerShell Modules since each module is contained in its own directory. However, I have some scripts that don’t belong in a module, but I would still like to version them. These scripts are in a “.\Scripts” directory that is added to
$env:PATH so I can easily run them from the command line. Since these scripts aren’t really related to each other, it doesn’t make much sense to create a single repository for the Scripts directory.
How should I version single scripts?
I’ve thought of the following options:
- Create subdirectory for each script/related scripts.
- Use temporary repositories until the script is “stable” then add the script to the main “Scripts” directory and version the collection of scripts as one. This would reduce the number of changesets introduced to the “Scripts” repository.
Is there a tool that better handles versioning single files? Is there better way for versioning single files with Mercurial? Any other ideas?
3 Solutions collect form web for “How should I version control (sort of) unrelated scripts in the same path?”
Grouping of files based on their functionality should be based on
2) Folder they are in.
Just give a proper name for the scripts. If there are multiple related scripts group them into a folder. Having one script per folder makes no sense. You end up with almost same number of folders as scripts.
All this in a single repository. Generally, people have multiple projects in a single repo. Creating multiple repos, especially for a few files means lots of overhead. If the script is not “stable” use branches. That is what they are for and merge them back.
And don’t worry how many “changesets” are there in the repo!
PS: Might seem a bit opinionated, but there is no real right or wrong answer for what you ask.
Step back, relax, and ask yourself if this is premature optimization. A primary benefit of using VCS is that you do not need to worry about starting with the “perfect” solution. DVCS tracks change history across renames & moves (use
hg mv, or try auto-detection with
hg addremove --similarity).
These scripts are in a “.\Scripts” directory that is added to $env:PATH so I can easily run them from the command line. Since these scripts aren’t really related to each other, it doesn’t make much sense to create a single repository for the Scripts directory
If the scripts are all in the same directory, it certainly makes sense to track them in the same repository.
- Use temporary repositories until the script is “stable” …
A “temporary” repo defeats the purpose of having a repo, which is to have a history of changes.
This would reduce the number of changesets introduced to the “Scripts” repository.
As @manojlds said, there is no reason to worry about the number of changesets. None.
- Put your experimental scripts in a directory like
- When a script matures, put it in
./Scripts/Foo/or whatever; use
hg mvto help Mercurial track the move/rename
- Or use
hg addremove --similarityto auto-detect moves/renames
- Or use
- The script’s change history is preserved and you can reorganize your script directories as your collection evolves
I think the chaps here have some good ideas and have pointed out you may be focusing a little too much on it. For completely carefree source control see Tome’s guide http://powertoe.wordpress.com/2010/12/12/why-every-it-pro-should-use-mercurial-for-source-control-with-their-powershell-scripts/
I’ve followed this method and found it very useful. 2 reasons I’ve found source control useful:
having a bad day and rewritten a script so that it doesn’t do anything you want it to and you can’t remember how to get it back!
changes in needs, sometimes you need a script to monitor or do something for a short period and then need it to revert to the original set up. easily done with source control.
As such, having all the scripts in one repo isn’t really an issue.
I did wonder if you can use it to synchronise computers as well (automatically instead of pushing\pulling when needed) but it’s not something I’ve had time to look at.