Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Unrelated scripts and version control

by loris (Hermit)
on Sep 23, 2010 at 07:24 UTC ( #861459=perlquestion: print w/replies, xml ) Need Help??
loris has asked for the wisdom of the Perl Monks concerning the following question:

Dear All,

As a follow-up to the discussion Perl apps and version control, I would like to know how people deal with multiple, unreleated scripts.

I use SVN and have a single repository with all sorts of stuff in it, varying from LaTeX files to applications in Perl and individual Perl scripts. However, I have been looking at git, mainly because of the advantages of it being a distributed system.

My problem is that for unrelated scripts, the git model suggests to me that each script would have its own git repository. Although this is obviously possible, I wonder how managable this would be in practice.

Does any one have any comments?



Replies are listed 'Best First'.
Re: Unrelated scripts and version control
by moritz (Cardinal) on Sep 23, 2010 at 10:08 UTC
    My problem is that for unrelated scripts, the git model suggests to me that each script would have its own git repository. Although this is obviously possible, I wonder how managable this would be in practice.

    (emphasis by me). Suggestions are just generally good ideas; it doesn't mean that you have to follow them, if they don't apply in your case.

    I often had the situation of having a repository with various stuff. Over time some of the scripts grew into larger projects, so I extracted them (and their history) into a separate repository, and deleted them in the original repo, leaving a note on where to find the files now.

    More repositories imply more administration overhead, so I only go the route of more repositories when I see a real benefit from it.

    Perl 6 - links to (nearly) everything that is Perl 6.
Re: Unrelated scripts and version control
by JavaFan (Canon) on Sep 23, 2010 at 09:56 UTC
    How unrelated are they? Are they all made for different customers? Do they live in different directories? Are they all used for different projects? Are they all shared between different sets of people?

    With git, the main thing to consider when creating a repository is "who is going to use it". Obviously, when for script x, you are collaborating with A, B, and C, and for script y, you are collaborating with D, and E, it makes more sense to have multiple repositories than if A, B, C, D, and E all work on x and y.

    If it's just a bunch of scripts that live in your ~/bin, it doesn't make a whole lot of sense to have separate repositories for each. But I'd create different repositories for /opt/whatever/make-the-world and /usr/local/bin/silly.

Re: Unrelated scripts and version control
by lima1 (Curate) on Sep 23, 2010 at 14:47 UTC
    One of the things I like about git is that it is easy and fast to set up a local repository. You have a small script and decide it would be nice to try a couple of things. Then just run git init and you have your local version control in your script directory. If you later want to collaborate, it's easy to clone the repository wherever you want. If you add the script to your one big SVN repository, it's there forever.

    I mean, for small things and finished projects, how often do you really need the version history? In git it's just this .git folder in your project directory. I didn't experience an administration overhead since my switch.

      Just running git init to create a local repository is obviously not such a big deal. However, if I want to collaborate with my colleagues, I have to set up a corresponding bare repository on a server that I can then push to. Doing this for a couple of dozen individual scripts seems like it might be unmanagable overkill.

      Regarding the history, I do want this for individual files and I don't have such things as "finished" projects. I mainly have stuff for myself, which either contains bugs or is not as good as it could be, or both.

      Perhaps I just need to try working with a small number of repositories and see how it feels. I gather that can always merge them at some later point.



        As I said, I didn't experience an overhead. In SVN, you normally need one step to prepare the directory for SVN import (e.g. the trunk/ branch/ merge directory structure) which somehow would correspond to git init. To publish it, svn import would correspond to git clone -bare.

        Your couple of dozen scripts are all unrelated? So there is no group of scripts your colleagues would likely want to fetch together?

        What I meant with my history comment was, I also used to have a single big SVN repository for almost everything. My SVN dump was huge at the end. But for most projects, I never actually needed the history later on. Now I have a decent backup system and git when version control is actually needed (collaboration, branching etc.). So much cleaner and better...

Re: Unrelated scripts and version control
by jandrew (Chaplain) on Sep 23, 2010 at 17:12 UTC

    I will be following this string due a personal interest as well. It sounds like what you are looking for is joining of a Content Management System combined with a Version Control System that supports software development. (I am assuming that didn't meet your needs)

    Non Software industries have systems like this for general product life-cycle management. However they are very hardware development and document driven. They stumble substantially when doing version control for software development. That doesn't even mention the large per seat fee associated with the proprietary nature of these packages.

    I also ask what are the available options?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://861459]
Approved by Corion
Front-paged by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2018-05-26 10:02 GMT
Find Nodes?
    Voting Booth?