Re: checking in links to source control

[Edward Peschko]

On Tue, Sep 11, 2001 at 01:15:34AM -0400, Greg A. Woods wrote:
> [ On Monday, September 10, 2001 at 18:32:06 (-0700), Edward Peschko wrote: ]
> > Subject: Re: checking in links to source control
> >
> > I beg to differ. Why should it *not* be a build system?
> 
> CVS is a version control system.  It does not build things -- it only
> tracks changes to things (usually just text source files at that).

Ok.

Before we go any further:

        1) I apologize for the knee-jerk reaction that I made in response to 
your knee jerk reaction. Knee jerk reactions seldom get you anywhere. And it 
also leads to both intolerance and to 'not thinking straight', 

        2) I am quite familiar with (g|p)make, GUI framework build managers 
like IDEA, installation managers like InstallShield. I've managed problems in
java, C++, perl and (a little) python, and have hacked up perl to be a build
management system. I find the gui tools more cumbersome than they are worth, 
like to stick with command-line tools. So I *think* I have good idea (IMO) 
where to draw the line.

So - those two things said, I feel that we are better off starting over. 

First of all, there is some merit to what you say about CVS not becoming a 
build manager like make. By 'build manager', I mean something that does 
releases, compiles files, and so forth.  

But I was a *bit* PO'd when I responded to your first comment inside your 
first knee jerk reaction - so feel free to disregard it. The post gets more 
coherent as it goes on however, so lend more credence to it as it goes on.

Second, I was thinking about it a bit more, and links are really just the tip
of the iceberg.

CVS = Concurrent Versioning System. Ok, so concurrent versioning system of 
what?  A person, or group(s) project. And what is a project made up of? A 
series of 'things'. 

So - who decides what *types* of things can go *into* a project? The tool 
itself?  Hardly. Why should that decision be left up to the tool?

The *group that is doing the programming itself* should decide on where 
the delineation between project and build lies, and the tool should their 
decision.

I say that the links that I want to check in lie on the side of the project,
and not the side of the build. You say they don't. Who's right? I maintain that
I am a priori because I *control the project* and you don't. 

You can give me advice that I'm not doing something in the best possible way, 
talk my ear off, or what have you, but when it comes down to it, the tool 
should not take the stance that 'whoa... you can't do that.. its not wise!'.
It should just get out of my way and let me store whatever I damn well please.

So, this isn't just about links. I claim that project owners know best what 
*types* of information that they store.  What types might include files,
sepcial files, etc.

And on my side, I'm not going to tell some MacOS programmer that they can't 
store resource forks. Why should I care? The more power the tool has, the 
happier he/she is and the more projects it can be used for.

So here's my proposal:

1) that CVS have a generic way of storing - and representing in storage - *any*
   type of data that can occur on an OS, and how they are stored. We already 
   have two types - 'file', and 'dir'. To that - on unix - we could add 
   'symlink', 'permission', 'user', and 'group'. On NT, we could add 'shortcut',
   'properties' (and god knows what else)

2) that this 'generic way of storing' is all due to work on the client side -
   the client 'serializes' the special files by making and storing them as 
   attributes inside the ,v file description itself. If the client can't 
   serialize them properly, then too bad.

3) that each attribute is handled by the client, but that only certain types of
   attributes are turned on by 'default', ie: that have intelligent defaults
   given the OS that they are working in, and that others need to be explicitly
   stated when put in. For example -

   cvs commit <link_path>

   can be on by default because there are no backwards compatibility issues, but

   cvs commit -p (preserve permissions on files on checkin)

   can not because old versions of cvs aren't capable of handling it.

4) On checkout, whatever attributes are set are processed by the client. If a 
   given attribute can not be processed by a client, a warning is given 
   (suppressible via an 'ignore' command line option or attribute) saying that 
   that file is not portable on a given system.

5) attributes can be programmed in the same way that apache can be extended:
   by modules that hook on to the the client and both do the serialization,
   and process it upon checkout. 

   However, I don't think that it should be *trivially* programmable. One should
   need to write a C-module to hook into the CVS code - this would prevent a lot
   of frivolous modules and keep the cvs source coherent. I think though that
   these modules should be released as part of the cvs tree, and not as separate
   entities.


6) things like diffs between versions in source control are handled by doing 
   diffs *with the tags intact*. 

   For example, suppose someone checks in a file with an attribute showing 
   permissions 644, and then checks in the same file with permissions 755.

   If they type:

   cvs diff -r1.1 -r1.2 <file>

   then it should show something like:

   < @permission=0644
--
   > @permission=0755

7) things like diffs between a version in source control and a version in a 
   directory are handled by:

   a) serializing the version in a the directory with all 'default' 
      serializations for the given os. 

   b) serializing the version in the directory with 'optional' serializations
      on the command line.

   c) comparing the resulting serialized file to the file inside CVS


Examples - 

   cvs commit linkname

head    1.1;
...
...
desc
@@
@link=/path/to/link

   cvs commit shortcut

head    1.1;
...
...
desc
@@
@shortcut=.... \
        attributes=archive
        shortcutkey=alt-x


Now - does anyone have any technical comments on how feasible this would be to 
implement? Or holes in my design that I am missing that I need to fill? I 
understand philosophical objections to my style of project management - they 
are duly noted - but I'd rather that the tool fit my versioning needs. 

Which at the basic level is to store a bunch of 'stuff' where stuff can be 
basically anything under the sun and not just files and directories. And which
is probably - but not necessarily - OS independent.

Ed