RE: checking in links to source control

[Thornley, David]

> -----Original Message-----
> From: Edward Peschko [mailto:address@hidden
> Sent: Friday, September 14, 2001 4:13 PM
> To: CVS-II Discussion Mailing List
> Cc: address@hidden
> Subject: Re: checking in links to source control
> 
> 
> 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
> > >
> > > 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.
> 
If this is done on an ad hoc basis, it might work.  At that point
it seems reasonable to do it outside CVS.  It really isn't difficult
to write simple wrappers around CVS.

> > 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?
> 
If you set the requirements to that level of detail, you can doubtless
come up with a standard solution.  Assume that's implemented.  Now, it
happens that I work on Linux and MacOS at home, and various Unixes and
MS Windows at work.  Perhaps somebody else does Mac only.  That's
four situations that need different methods of serialization.

Actually, MacOS 9 privileges don't map at all well to Unix permissions,
so everybody serializing privileges to both is going to have to
roll their own.

There is quite a bit of support for running CVS clients on the Mac,
by the way, with three implementations.  Let's not gratuitously
make things hard for Mac users.

So, we find that permissions require ad hoc solutions in many common
circumstances.

> Like any programming technique, you don't use serialization 
> for *everything*.
> You wouldn't serialize a database, for example.  
> 
Why not?  Too long?  I've got a serialized database in a directory
around here somewhere.  If I were to put it in CVS, it would be nice
if CVS made more efficient use of /tmp and memory, but that's not
an overwhelming problem.

> 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:
> 
Really?  There's lots of things that can be serialized.

> 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).
> 
Depends on how detailed you want to be, and how much differences there
are with the directories.  Remember the symbolic link issue:  how much
commonality is there between Unix symlinks, Windows shortcuts, and
Macintosh aliases?

(It's been over a decade since I did serious development on an OS
that didn't have subdirectories.  Are there any still out there?)

> 2) permissions - cross-platform for all of unix, 
> cross-platform for all of NT,
>                  cross-platform for all of Mac.
> 
The Mac now subsumes much of Unix, since modern Macs ship with
a Unix installed (it's called MacOS X, but it's mostly BSD with
some fancy interface stuff on top).  

> 3) user/group - cross-platform on all of unix. cross-platform 
> for all of NT.
> 
Again, what about MacOS, or people who want to use multiple
platforms?  The stuff I work on at home is intended to compile and
run on multiple platforms, right out of the box (well, tarball).

> 4) binary data - cross-platform on all of unix, && probably 
> all of NT && mac,
>                  given the correct supporting programs or routines
> 
Um, no.  There are methods to converting arbitrary files to
text or text-like representation.  They are useless for anything
except transmitting the file to another system.

> 5) symlinks, shortcuts, aliases  - cross-platform on all of 
> unix, NT, and mac
>                                    ie: symlinks are 
> cross-platform on  
> 
They don't necessarily map all that well onto each other.

The list of converters you're proposing is incomplete, and simply
won't fit everybody's needs.  It is necessary to do this mostly on
an ad hoc basis.
> > 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. 
> 
You have completely misunderstood the binary file problem.

For best use, CVS needs to be able to merge files and come up
with something useful.

The neat thing about programming language source files is that,
from a base file, two sets of changes can be automatically merged
and produce something that is probably correct.  This is the
fact that makes CVS well suited for concurrent development and
branching.

It is trivially possible to convert binary files to text files of
the sort CVS nominally handles.  Read in the binary file, and write
it out with hex digits, throwing in an end-of-line every 80 characters.
Presto, it's serialized.

These files can be stored in CVS, and CVS will be happy to merge
two sets of changes.

What is the chance that such merging will do anything useful?  It
will most likely either come up with entire files conflicting or
it will break something vital in the format and create a useless
file.

If you can serialize binary files of a given variety into a text
form where merging does something useful, that's nice, but that's
largely going to be ad hoc.  It may be worthwhile adding functionality
to support this to CVS, but I'd really like to see an example where it
would be useful before supporting it.