Re: checking in links to source control

[Edward Peschko]

On Fri, Sep 14, 2001 at 03:59:03PM -0400, Greg A. Woods wrote:
> [ On Friday, September 14, 2001 at 11:59:03 (-0700), Edward Peschko wrote: ]
> > Subject: Re: checking in links to source control
> >
> > Sorry if I'm not being clear - but to me, serialization is exactly that - 
> > taking
> > something that is not a file, turning it into a file, and then storing that 
> > file for access. 'Deserialization' is the process of reversing this, turning
> > a serialized file back into its non-file status.
> 
> That's definitely not 'serialisation' (which as a verb is probably the
> act of giving some set of things a unique identification that can be
> used to put them into a fixed order, though as a noun is simply the
> publication in serial form).  I'd call it "adding a level of
> indirection", though maybe that's not even an ideal description.....

>From 'http://java.sun.com/products/jdk/1.1/docs/guide/serialization/' (sorry 
that I didn't get something more standard on the spur of the moment, but
hell, I'm at work and already taking more than enough time on this subject):

Object serialization:

Object Serialization extends the core Java Input/Output classes with support 
for objects. Object Serialization supports the encoding of objects, and the 
objects reachable from them, into a stream of bytes; and it supports the 
complementary reconstruction of the object graph from the stream. 
Serialization is used for lightweight persistence and for communication via
sockets or Remote Method Invocation (RMI). The default encoding of objects 
protects private and transient data, and supports the evolution of the classes..

etc,etc,etc.

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.

> > And that's exactly what I want to do -  I want to build in serialization
> > into CVS.
> 
> That's such a silly thing to want to do in CVS that I can't even begin
> to explain why it's so.  There are, as I said, literally hundreds if not
> thousands of ways to do it.  Some better than others, and many platform
> dependent.  I.e. there is no "one true way" to do this kind of thing.

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.

> This *is* _the_ perfect example of ideal place for ad hoc solutions.
> 
> The requirements for a generic solution are just too unwieldy.  Only you
> can invent the right kind of wheel for your specific requirements, and
> that generally means what you invent will never be perfect for anyone else.

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?

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

No, you only use it for things that it makes sense to use on. I can think
of only a few things that fall under this category:

1) directories - in fact, useful serialization in this case would probably be 
   cross-platform (given pretty much any platform. Maybe VMS might have some
   issues).

2) permissions - cross-platform for all of unix, cross-platform for all of NT,
                 cross-platform for all of Mac.

3) user/group - cross-platform on all of unix. cross-platform for all of NT.

4) binary data - cross-platform on all of unix, && probably all of NT && mac,
                 given the correct supporting programs or routines

5) symlinks, shortcuts, aliases  - cross-platform on all of unix, NT, and mac
                                   ie: symlinks are cross-platform on  



> In fact a re-invented wheel is the singular most elegant solution
> possible in this scenario.

no, it isn't. If you do serialization correctly, you don't need to do a thing
(except add a flag or two when you are checking things in)

> Any attempt to hack some half-assed scheme into CVS can only result in
> an ugly mess that meets very few people's requirements, and which will
> inevitably collides with real-life uses of ad hoc solutions, and which
> will causes more confusion than it can ever solve.  Even worse it's

It only causes confusion if you use it (you don't have to you know). 

> bound to be either highly platform specific, or to require some
> additional "little language" be built into every CVS client (not to
> mention protocol extensions, etc.).

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.

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.  For backwards compatibility purposes, of course you would need to add 
extra flags in order to get the functionality of say, adding permissions to 
RCS files.  And if a project uses symlinks, of course the file that is 
serialized into CVS is going to have a notice in it telling the clients the 
need to upgrade.

> Why do you fight the easy way so much?

Because it isn't the 'easy way'. There's another discussion going on right now
about a replacement for CVS simply because it doesn't handle binary data well.
You have attributes and serialization? Voila - problem solved. Luke - in that
discussion you pointed out - had a really cool idea on how to track down 
changes to his config files on linux.  And unfortunately, Kaz got the better
of him with the same kind of FUD. 

Look, why do you fight telling me exactly the process for submitting/applying 
patches?  When I write them, you might *just* find them useful...

Ed