7

My original problem is that I have a directory where I write various scripts. Each of them is independent of others, and usually one-file-long. I want to have some versioning applied to them, but I have the following problems/requirements:

  1. I don't want to have to store each small script in a separate directory!
  2. I don't want to store them all in one repository OTOH, as they are completely unrelated, and:
    • some of them may later grow to more files (and then they will need a separate dir),
    • I sometimes want to copy one of them to a different machine (and I want to clone the whole repo).
  3. I want to benefit from (distributed) version control mechanisms -- at least:
    • "infinite" number of revisions,
    • ability to clone repositories on different computers,
    • ability to do "atomic" multi-file commits.

Is it possible?
I'd prefer to do it in some mainstream distributed VCS (a solution using Mercurial would be preferable, but I'm not fixed).

EDIT: the solution has to be free (at least "as in beer") and cross-platform (at least Win32 & Linux).

Related, but didn't help:

Community
  • 1
  • 1
akavel
  • 4,789
  • 1
  • 35
  • 66
  • 5
    It might help if you explain why you have these two conflicting goals: together in one place; separate version control repositories. Thinking about package installation on linux there would be a location for the package to install and then as part of installation they would be linked into common location for access (i.e. /usr/bin). Could it be that an installation or deployment process allows you to meet your goals? – splonk Apr 25 '11 at 00:16
  • As I said, I need it for storing some ad-hoc scripts I write for various purposes (really very general - kinda `$HOME/bin` dir). Your idea is interesting, but unfortunately has several disadvantages for me: handling a separate dir and deployment process is often too much (mental) overhead (a script can be a simple 2-liner); also, I think such deployment would become an issue if the script wanted later to grow and include some dependencies stored in a subdir. – akavel Apr 26 '11 at 11:32
  • 2
    @splonk: Thanks for wishes. Please refrain from _ad personam_ comments. – akavel Apr 26 '11 at 12:22
  • 1
    Didn't mean it as a personal attack. To clarify: As the solution deviates from the norm the cost gets higher (worst case being you create your own VC). Recommending that you balance that against the cost of achieving your goals in other ways. That's all. – splonk Apr 26 '11 at 14:01
  • 1
    @splonk: Thanks for the clarification. As for your arguments, these are actually the reasons why I asked the question at all - that I found the problem difficult for _me_, and hoped that maybe someone else knows, or is smarter and finds it easier to invent, some solution (and maybe even has already implemented it). – akavel Apr 27 '11 at 10:06
  • If the scripts are totally unrelated why would they need to be in the same directory? Seems not logical to arrange it that way. And if the directory that they share needs to be on the search path, then seperating their development location and using an install step that copies them to the final location seems more appropriate. – lothar Apr 27 '11 at 22:51

7 Answers7

5

These requirements seem pretty "special" to me, so here is a solution on par with them ^^

You may use two completely different VCS, in the same directory. Even two "instances" of SVN might work: SVN stores its metadata in a directory called .SVN and has (for historical reasons regarding ASP) the option to use _SVN. The Directory listing should look like this

.SVN    // Metadata for rep1
_SVN    // Metadata for rep2
script1 // in rep1
script2 // in rep2
...

Of course, you will need to hide or ignore the foreign scripts or folders from each VCS...

Added: This only accounts for two scripts in one folder and needs one additional VCS per script beyond that, so if you even consider this route and need more repositories, rename each Metadir and use a script to rename it back before updating:

MOVE .SVN-script1 .SVN
svn update
MOVE .SVN .SVN-script1
Stephan B
  • 3,671
  • 20
  • 33
  • 1
    Strange questions. Stranger answers. +1 :) – Noufal Ibrahim Apr 26 '11 at 11:38
  • 1
    Seems I somehow missed this answer appearing just before I started writing my own description of the same idea :) That said, I'd still much prefer having such a solution "pre-packaged" to having to write my own script to implement it. – akavel Apr 26 '11 at 12:01
  • @akavel I dont't think there is something pre-packaged for this scenario. If a simple shellscript won't do, the next best solution would be to drop one of the requirements. – Stephan B Apr 26 '11 at 12:15
  • Ok, as of today, this idea sounds most interesting to me, when considered with some level of automation layered on top (`hashtable: filename->repoId` + auto-mv-repo?). Although I should probably check the "Mercurial convert extension" as well, and it has chances to prove more practical. Thanks to everybody who contributed ideas! :) – akavel Apr 28 '11 at 07:18
1

You can create multiple hidden repository directories and symlink .hg to whichever one you want to be active. So if you have two repositories, create directories for them:

.hg_production
.hg_staging

Then to activate either of them just do:

ln -sf .hg_production .hg

You could easily create a bash command to do this. So instead you could write something like activate-repo production, which would run ln -sf .hg_production .hg.

Note: Mac doesn't seem to support ln -sf so instead you'll need to do:

rm .hg; ln -s .hg_production .hg
Jonathan Potter
  • 2,981
  • 1
  • 24
  • 19
1

Why don't you simply create a separate branch (in the git sense) for each (group of) script(s)?

You can develop them individually as you please. Switching to a branch will show you only the scripts from that branch. It's sort of like directories but managed by the version control system. If you later want to pluck a branch out into another repository, you can do that and if you want to combine two scripts into a single project, you can do that as well. The copying them to the different machine point might be a problem but you can clone the branch you're interested in and you it should work for you.

Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169
  • The "Switching to a branch will show you only the scripts from that branch" part sounds like the main issue to me: if I understand properly, then before calling any of the scripts, I'd have to recall in which branch it was stored and switch to that branch. Apart from uncomfortable-ness of having to issue additional command each time: What if I wanted to pipe results from one script through some other script (from other branch)? – akavel Apr 26 '11 at 11:53
  • You can avoid the naming issue by naming the branches after your scripts. The second point was something you didn't mention in your original requirements and it points to these scripts being usable together which is an argument for putting them in a single repository. – Noufal Ibrahim Apr 26 '11 at 12:00
  • The "first" script could be very specific (with knowledge of some particular file format intricacies), while the "second" one highly general (like "wc"). I'd be very interested to move the second one between computers, while the first one can be completely useless in different environment. – akavel Apr 26 '11 at 12:29
  • Makes sense. I'd be more inclined to bunch them all together as a "utils" repo (similar to the way I do with my config repo that contains my emacs and zsh config files). – Noufal Ibrahim Apr 26 '11 at 13:55
1

Another proposition for my own consideration is "Using Convert to Decompose Your Repository" article on hgtip.com. It fails as a "standalone" solution, but could be helpful as an addition to the "mv .hgN .hg / MOVE .SVN-script1 .SVN" idea.

akavel
  • 4,789
  • 1
  • 35
  • 66
0

I can only think of these two lightweight versioning systems:

1) Using Dropbox with the Pack-Rat upgrade, to keep a full history of versions for each file automatically backed up and with the possibility to be shared with multiple Dropbox users: https://www.dropbox.com/help/113

If you have multiple machines managed by the same user (you), the synching would be automatic. Also if the machines are in the same LAN, Dropbox is smart enough to sync the files over the local network, so big files shouldn't be a worry.

2) Using a 'Versions' aware text editor for Mac OS X Lion. I'd expect TextMate, Coda and other popular Mac code editors to be updated to support this feature when Lion is released.

Julio Gorgé
  • 10,056
  • 2
  • 45
  • 60
  • 1
    Ah, thanks for ideas; unfortunately, they miss some requirements that were subjectively obvious to me when writing the question. I'll have to update the text to make them visible. – akavel Apr 26 '11 at 11:06
0

UPDATE (2016): Apparently, a guy named Cosmin Apreutesei created a tool named multigit, which seems to implement what I wished for in this question! If you ever read it, thanks a lot Cosmin! I've started using your tool this year and find it awesome.

I'm starting to think of some kind of an overlay over Mercurial/git/... which would keep a couple "disabled" repository meta-directories, let's say: 

.hg1/
.hg2/
.hg3/

etc., and then on hg commit FILENAME would find the particular .hgN that is linked to FILENAME, and would then temporarily:

mv .hgN .hg
hg commit FILENAME
mv .hg .hgN

The main disadvantage is that it would require me to spend some time writing the tool. Or does anybody know of some ready-made one like this? If you do, please post as a full-featured answer (not a comment), I'm more than willing to accept it.

akavel
  • 4,789
  • 1
  • 35
  • 66
  • I tried doing this by dynamically resetting the GIT_DIR variable but I thought it inelegant. – Noufal Ibrahim Apr 26 '11 at 12:00
  • @Noufal: Would you care to elaborate a bit more? What is GIT_DIR? Why would you think it inelegant, what disadvantages do you see? – akavel Apr 26 '11 at 12:24
  • I guess the fundamental idea of having multiple repositories in a single directory didn't appeal to me. Also, I tried to keep the repos in a separate sub directory which git didn't like. – Noufal Ibrahim Apr 26 '11 at 13:53
0

How about a compromise between 1 and 2? Instead of a folder+repo for each script, can you bundle them into loosely related groups, such as "database", "backup", etc. and then make one folder+repo for each group? Then if you clone a repo on another machine, you're only pulling down a smaller number of unrelated files. (Is the bandwidth/drivespace really a concern?) To me, this sounds WAAAY simpler than all of the other suggestions so far.

(Technically this approach meets your requirements because (1) each script isn't in its own directory, (2) not all scripts are in the same repository, and (3) you can easily do this with any popular DVCS. :D)

Jim Bolla
  • 8,265
  • 36
  • 54
  • Unfortunately, I'd still have a problem with this approach, as it'd require me to do "premature categorization": before I could start coding, I'd have to think hard which category it's gonna belong to. That might not be so clear (to me) at this point, and if I made my choice wrongly, I'd be punished by (AFAIK) not being able to easily move the script (with history) between the repos later, to adjust the decision. As for simplicity, I think I'd prefer even a _technically_ more complicated solution, as long as it's simpler from _usage_ perspective. – akavel Apr 27 '11 at 09:40
  • 1
    Sadly I don't think you're going to find a solution that does exactly what you want, but I wish you luck. Since you're averse to any pre-organization, my advice would be to simply put all the files into a single Mercurial repo and then IF the day comes that you decide one or more of them should be on their own, use Hg's [Convert extension](http://mercurial.selenic.com/wiki/ConvertExtension) with a filemap to split the repo. – Jim Bolla Apr 27 '11 at 14:51
  • I think the solution with "Convert extension" is also quite a good idea, and I'll have to check it out, especially with regards to what's happening to history. If it proved to fulfill my desires, I think it would match great with the 'mv .hgN .hg' idea, and together they have the potential to make the "golden combo". – akavel Apr 28 '11 at 07:24