Re: checking in links to source control

[Greg A. Woods]

[ On Friday, September 14, 2001 at 14:13:20 (-0700), Edward Peschko wrote: ]
> Subject: Re: checking in links to source control
>
> Sorry you haven't heard the term. Its pretty common in OO - here the things
> being serialized are objects, they are being serialized into bytes, and they
> are being reconstructed by a remote host.

I generally go for a copy of one of my many dictionaries, or some
encyclopedia, or even www.dict.org, to learn the meaning of something.

However the specific case of "object serialisation" you described is not
really applicable outside the OO paradigm, nor to something that's
primarily attribute control, or even the initiation of actions to
instantiate attributes.  Changing an object representation into a
canonical byte stream is quite a bit different conceptually than
representing the desired state of file attributes, or actions that
change file attributes, or desired symlink locations and their targets.

> hmm. My ears are open. Give me a 'hundred useful different ways' in which
> you could serialize a symlink. And don't give me stuff about cross-platform
> support between shortcuts && aliases - I want to serialize a *symlink* so
> that one type of platform (Unix) can share them. We'll worry about 
> translations later.

How about we just start with a simple list of little (and not so little)
languages in which you could implement a solution to creating and
managing symlinks:

        make, gmake, sh, csh, ksh, perl, python, tcl, ruby, pike, C,
        STk, drscheme, elisp, elk, java, smalltalk, lisp, c++

No doubt you can add more examples of your own to that list.

That's not to mention custom tools more suited directly to doing this
kind of thing (but otherwise more often used to automate sysadmin tasks)
such as cfengine, install, and mtree (and no doubt others).  Obviously
you could write yet another similar tool in the language of your choice
too.

I'm sure you can come up with solutions suitable for your specific needs
and implemented in your language of choice.  The very simplest though is
a simple shell statement that'll create one symlink:

        #! /bin/sh
        ln -fs target link

That's about as specific an example I can give without knowing your
exact requirements in detail (and no, please don't send them to me, at
least not without attaching a certified retainer check made out to
Planix, Inc. :-)

> examples please, again. Perhaps this time on permissions.. How would you 
> serialize permissions in different ways, again with the guide that the
> permissions will only be shared on the same OS?

Personally I'd probably just write a little script in whatever language
seemed most convenient at the time and instruct users to run it after
checking out the working directory or after unpacking a source release.

Usually what I use is just /bin/sh statements from within a makefile.

> Like any programming technique, you don't use serialization for *everything*.
> You wouldn't serialize a database, for example.  

You're not serializing anything here -- you're managing attributes, and
in particular ensuring that they're in a specific state.  The easiest
way to do that is to put them into the desired state, by force if
necessary.

Once upon a time when I was using CVS to track changes to system related
files I wrote an ~3500 line makefile and a bunch of little shell scripts
to assist.  That stuff managed about 280 files and symlinks, including
installing them in their correct destinations and ensuring they had the
correct ownerships, permissions, etc.

Today I think I'd use cfengine or something similar (it wasn't available
back when I started my makefile).

In the mean time I've gone back to simply using SCCS or RCS on a
per-file basis and using 'mtree' to manage ownerships and permissions.
I don't use symlinks that much so generally I don't have to try to track
changes in them very often.

> Hence, the need for cvs to take in pluggable modules. Apache faced this very 
> issue when they were starting out; people wanted apache to do things that 
> weren't 'standard', hence they came up with the module scheme... works pretty
> well.

CVS already has pluggable modules.  They're invoked from the
CVSROOT/*info files.  They don't do what you seem to want though....

> As far as 'protocol extensions' go, I already mentioned that the attributes 
> for 
> serialized thingys could be put at the top of the 'data' section of the RCS 
> files.

that doesn't help and is only a tiny part of the solution -- you have to
communicate your extensions to the client side and then translate them
into actions.

If I read your intentions correctly you're also ignoring some
fundamental change management issues too.  Remember what I said before
about the requirement to handle a situation where a name in the
hierarchy transitions from being a link to being a file and then back to
being a link, perhaps with the links having several different targets
just as the file might have different content at different times?  You
need to ensure that all those changes can be tagged, diffed, merged,
etc. just as I can do with my scripts or makefiles or mtree data files.

> Because it isn't the 'easy way'.

Oh, but it is far easier to manage file attributes and create symlinks
and such from script or makefile.  You've apparently only scratched the
surface of the issue of trying to integrate such functionality of very
questionable use into CVS.

> There's another discussion going on right now
> about a replacement for CVS simply because it doesn't handle binary data well.

I think you're seriously confused.  CVS doesn't need replacing.  It does
what it was designed to do reasonably well.

Whether new tools need to be implemented to do other things, or not, is
a different concern, and certainly not something to confuse CVS with.

Similarly CVS doesn't need to become a build system, even for the most
basic task of trying to manage file attributes or symlinks.  That's the
job of your build system.

"Use the right tool for the job."(tm)  :-)

Or as George Double-You Shrubbery would no doubt say:  "Make no mistake
about it!  CVS is not a build system!"

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>