Concerning Re: exclude parts of a file from ve
John Peacock wrote on 5 Aug 2008, 9:37, at least in part:
> Jan Hendrik wrote:
> > can parts of a file be marked to be excluded from versioning? Like
> > a comment in code the parser ignores?
>
> Short answer: no, a file is versioned or not. The Subversion client
> has no clue what is inside the file itself; it is all bytes (and
> whether the file is binary or textural is based on a somewhat fragile
> heuristic).
My train of thought was kind of inspired by both svn:keywords and
the usual comments in code parsers ignore. Something in the line
of
*/begin svn-ignore-this/* and */end svn-ignore-this/*
which would mean nothing to Perl or a browser or any other parser,
but svn diff would skip over it.
<----straying off-topic for better illustration---->
Basically the script has
- a basic config area (separating this into a config file is no issue);
- code to extract a suitable title, description and other stuff from the
input file into variables, mostly done by regex. In this part
adjustments can happen, and are likely to be general
enhancements I want to keep and be versioned. Actually almost
always it would be just me to do anything here;
- production area where static HTML/PHP code and the content of
the above variables are merged and printed to file. This part is
likely to be modified every time, as to where the image goes or
adding some common paragraphs (e.g. a short biography), but
generally this is nothing I want to have versioned. I would like to
hide this from SVN operation. Neither I don't see how I could place
this into a config file without ending up with two config files (for this
and for the above). Remember I have to deal with people using
computers for writing copy, but not much more, having them
understand update & commit is on the edge, dealing with conflicts
is, well, dealing with conflicts... ;);
- some helper functions.
<----end of straying off-topic---->
> > I have a Perl script that takes an input file (actually a listing of
> > items a Word macro has preformatted for HTML), extracts several
> > things for title, description, keyword tags, adds an illustration
> > and some other things, and creates a separate file for each item.
> > Naturally it works best if the items in the listing have a good deal
> > of similarity, and likewise in every case of use there have to be
> > some adjustments made to the Perl code to meet specific
> > requirements. However, there is no reason to have these adjustments
> > ending up in the repository. Some of these actually enhance the
> > script for future abuse though and should be versioned yet, as I
> > would like the script as such.
>
> Slightly longer answer: generated files should normally not be
> versioned (i.e. added to the repository). The one common exception to
> this is storing compiled code as part of a tag, so you can always
> regenerate a tag/release at any point in the future (though you can
> eliminate this exception through the use of pegged externals in your
> tag for shared code).
>
> I think that with a slight bit of refactoring, you should be able to
> partition the versioned part of the script with the generated portion.
> It is common with Perl to generate a base class and multiple derived
> classes which override portions of the base class behavior. Each of
> these classes could be versioned, but the base class would change
> slower than the derived classes.
Sorry for having been not clear enough, John. The stuff the script
generates (HTML files) shall go into the repository all right.
I have to think about your suggestion of refactoring. I'm not that
much of a Perl writer (or any programming for that matter) to
completely understand base classes and derived classes or how
the script could make use of them, but it sounds worth to digg into
it.
Thanks, John.
Jan Hendrik
---------------------------------------
Freedom quote:
Wohltaten am falschen Orte ist gleich einer Übeltat.
-- Marcus Tullius Cicero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-05 18:29:49 CEST