[GLLUG] Subversion

Charles Ulrich charles at bityard.net
Fri Jan 25 22:08:28 EST 2008


2008/1/25 Frank Dolinar <frank.dolinar at comcast.net>:
>
>  Marshall, et al.,
>      I've been thinking about our discussion of Subversion / TortoiseSVN /
> etc. from last night.
>      I think I have a reasonable grasp of what it does.
>      I got the impression from Jeff that you have a written description of
> how it is actually used.  That's the piece I'm currently missing.  How is it
> used on a day-to-day basis.  Sometime soon -- probably within the next two
> weeks -- I need to put together enough of an explanation for myself and my
> colleagues at work so that we can begin using it effectively no later than
> the middle of next month.

The best reference to Subversion is The Subversion Book. It's not
large and you don't have to read much of it in order to get a solid
understanding of how to use and administer Subversion:

http://svnbook.red-bean.com/

For a quick-reference kind of thing, a number of cheat sheets abound:

http://www.google.com/search?q=subversion+cheat+sheet

Also, don't forget that subversion has its own built-in help system:

svn help
svn help commit

>      The system is set up and running on one of our servers at work and I've
> been able to load a few things into it, but they're just some initial files.
>      I'm working on an approach to a presentation, with some specific code
> evolution in about ten steps.
>
>      Based on what I've read, and the discussion last night, I see no
> particular reason to change the /trunk  /branches  /tags setup for now.
>
>      Agreeing with Clay's comment, I do expect to keep each application
> development project in a separate repository.  I presume that means
> something like Inventory as an application.  I am not sure whether that
> means "project" in the sense that Microsoft uses the term in developing a
> .Net "solution", which may contain multiple so-called "projects".  Please
> advise / clarify if possible.

I think you've got the right idea. Each project should have its own
repository. Subversion was designed to accommodate open sources
developers with their typical handful of projects.  Adding layers
above that sounds like a Microsofty thing to do. If you really need a
hierarchy level above "projects", then you'd probably be setting up an
entirely different development server anyway.

>      However, the documentation I have suggests that only certain files
> should be kept in the repository.  The implication seems to be that only
> human readable source code should be included and that any binary or .dll
> files should not be included.  Given that we are using .Net, that makes
> sense, but any clarification here would also be useful.

Subversion will handle any kind of data just fine. It's not nearly as
efficient at dealing with changes in binary files as it is with text
files, though maybe this has changed in recent releases. The only rule
of thumb here is that you generally don't want to include binaries
which can be easily generated from the plaintext content already in
the repository (such as executables or databases).

For my web projects, I always bundle a shell script that creates and
populates the database that the project will use. It also makes
reinitializing the database easier whenever I decide I want to change
the structure.

>      There was a secondary discussion about bug tracking.  I'm aware of
> several such tools, including "Bugzilla".  Clay mentioned something else.
> I'm also aware of a highly recommended commercial product called FogBugz.
> Any comments on any of these would be appreciated.

I only have experience with Bugzilla and I can say that it is good at
what it does. The only downside to it is that it's written in Perl.
Which is fine, though, because it's one of the few really well-written
Perl applications. Just don't try to use it for anything else but
bug-tracking. :)

Charles


More information about the linux-user mailing list