Follow-up: Dropping the ball on version control / Importing snapshots into Subversion

As a follow-up on yesterday’s text ([1]) on adventures with version control:

1. When I speak of commands like “svn add”, it is implied that the right filename (filenames, directory name[s], or whatever applies) is given as an argument. I should have been clearer about that in the original text. Depending on the exact command, a missing argument will either lead to an error message or an implied default argument. The latter might, in turn, lead to highly unexpected/unwanted results.
2. During my imports, I did not consider the issue of the executable bit. In my past experiences, Subversion has not necessarily and automatically applied it correctly, forcing manual intervention. As it happens, this time around, it was correctly applied to all executable files that I had, which might or might not point to an improved behavior. However, had I thought ahead on this issue, I might* have complemented any “svn add” with an “svn propset svn:executable ON” when the file to be added was executable, and anyone writing a more “serious” script should consider the option. (Ditto with the manual addition of an executable file.)

   *In the spirit of “perfect is the enemy of good”, cf. [1], and noting that the script was never intended to be used again after the imports: Would it be more or less effort to improve the script or to just do a one-off manual correction at the end of the imports? (Or, as case might have had it, a one-off manual correction after I tried to run a particular file and was met with an error message?)

3. Something similar might apply to other properties. Notably, non-text* files are given an svn:mime-type property in an automatic-but-fallible manner. Checking the few cases that are relevant for my newly imported files, I find three files, a correctly typed PDF file (accidentally included in the repository, cf. [1]), a correctly typed JPEG image (deliberately included), and a seemingly incorrectly typed tarball (accidentally included).**

   *Situations might exist where MIME/media types are wanted for text files too. These, too, would then need manual intervention.

   **Gratifyingly, there has been no attempt to mark a text file as non-text, an otherwise common problem. See [2] for more on this and some related topics.

   Seemingly? Looking closer at the tarball, it turns out that the tarball was broken, which limits what Subversion could reasonably have done. My checks comprised “tar -xf” (extract contents), “tar -tf” (list contents), and “file” (a command to guess at the nature of a file) all of which were virtual no-ops in this case. (Why the tarball is broken is impossible to say after these few years.)

   However, the general idea holds: Subversion is not and cannot be all-knowing, there are bound to be both files that it cannot classify and files that it classifies incorrectly, and a manual check/intervention can make great sense for more obscure formats. Note that different file formats can use the same file extension, that checking for the details of the contents of a file is only helpful with enough knowledge* of the right file formats (and, beyond a very cursory inspection, might be too costly, as commits should be swift), that new formats are continually developed, and that old formats might be forgotten in due time.

   *Not necessarily in terms of own knowledge. I have not researched how Subversion makes its checks, but I suspect that any non-trivial check relies on external libraries or a tool like the aformentioned “file”. Such external libraries and tools cannot be all-knowing either, however.

4. An interesting issue is to what degree the use of version control, some specific version-control tool, and/or some specific tool (in general) can affect the way someone works and when/whether this is a bad thing. (Especially interesting from a laziness perspective, as discussed in [1].) The original text already contains some hints at this in an excursion, but with examples where a changed behavior through version control would have involved little or no extra effort. But consider again the moving/renaming of files and how use of Subversion might lead to fewer such actions:

   Firstly, a mere “mv” would be turned into a sequence of “svn move”, “svn status” (optional, but often recommendable), and “svn commit -m” with a suitable commit message. Depending on the details, an “svn update” might be needed before the commit.* Moreover, some manual pre-commit check might be needed to avoid a malfunction somewhere: with no repository, it does not matter when the issue is corrected; with a repository, it is better to avoid a sequence of commits like “Changed blah blah.”, “Fixed error in blah blah introduced in the previous commit.”, “Fixed faulty attempt to fix error in blah blah.” by making sure that everything is in order before the first commit. Obviously, this can lead to a greater overhead and be a deterrent.**

   *I have a sketchy record at predicting when Subversion requires this, and am sometimes caught by an error message when I attempt the commit. (Which leads to a further delay and some curses.) However, many (most? all?) cases of my recent imports seemed to involve a sequence of “svn mkdir” to create a new directory and “svn move” to move something into that directory. Going by memory from the days of yore, simultaneous changes of file position and file contents might lead to a similar issue. (Both cases, barring some tangible reason of which I am unaware, point to a less-than-ideal internal working of Subversion.) For use with multiple workspaces, say in a collaboration, a change of the same file(s) in the repository by someone else/from another workspace is a more understandable case.

   **As a counterpoint, it can also lead to a more professional approach and a net gain in a bigger picture, but that is irrelevant to the issue at hand, namely, whether use of Subversion can lead to fewer moves/renames. The same applies to the “Secondly”.

   Secondly, without version control, it does not matter in what order changes to data take place—begin to edit the text in some regard, move it, continue the ongoing edit.* The same might be possible with version control, but a “clean” approach would require that the move and the edit are kept apart; and either the edit must be completed and committed before the move, or the current state of the edit pushed aside, the move made and committed, the edit restored, and only then the edit continued. Again, this increases overhead and can be a deterrent. It can also lead to moves being postponed and, witness [1], postponing actions can be a danger in its own right.

   *Here I intend an edit and a move that are independent of each other—unlike e.g. the issue of renaming a Java class mentioned in [1], where the two belong together.

   (With older version-control systems, e.g. CVS, there is also the possibility that the move terminates the history of the old file and creates a new history for the new file, as there is no “true” move command, just “syntactic sugar” over a copy+delete. History-wise, this is still better than no version control, but the wish not to lose history might be an additional deterrent.)

5. Subversion has some degree of configurability, including the possibility to add “hooks” that are automatically executed at various times. I have no greater experiences with these, as they are normally more an admin task than a user task, but I suspect that some of what I might (here or in [1]) refer to as manual this-or-that can be done by e.g. hooks instead.
6. Remembering to write “an svn […]”, instead of “a svn […]” is hard.

Advertisement