Yes, that's exactly what i want: a working file must be private unless
the developper as decide to share it . An individual developper is not
impacted by external changes (like with the "LATEST" rule in clearcase)
and doesn't interact with other developpers. That's very important in
SCM !
> > > If I have to check in all files at once, it is even more important
> > > that I be able to have multiple "views". What if, in the middle of
> > > a big change, I make a small fix that I want to check in
> > > independently?
> >
> > It's impossible. If you want to go back, you have to put a label on
> > each step you want and, set the $CONFIGURATION to this label.
>
> Again, this seems exceedingly restrictive.
Regression is exactly what we try to avoid when we work under SCM. What
is done is done. If you really want, you can labelize after each write
but your must NOT modify the past !
Labelizing is the same things that doing ci/co but at a coarser grain
This level must exactly match your needs ( ... and with less overhead).
> > > You just threw away the most useful feature of filesystem
> > > integration: comparing different versions. How do I do this if
> > > everything is keyed off $CONFIGURATION?
> >
> > With 2 process and shared memory, it should be possible but i haven't
> > though deeper.
>
> Standard tools, please. (Can I tell you how painful I would find
> ClearCase if I had to use their diff instead of GNU diff?)
Ok, now i am more oriented throw a userspace SCM. Perhaps i will use a
naming convention a la clearcase (ie: filename@@label ) and, with this
namespace, you will be able to use all your favourite UNIX tools.
> I said, compared to CVS, not ClearCase! The analog in CVS is
> - cvs checkout
> - cvs update
>
> The only advantages your have are 1) you don't have to specify the
> repository/modules and 2) you're faster.
CVS deals with versionning and not configuration management, so you
can't compare them.
>
> Also, you have left out at least one important step. Say I set
> CONFIGURATION=A, do my work, and label it with B. How do other
> developers know to switch to B?
Labels are public and i hope there are meeting organized between
developpers !
> What if they're already working
> off A--how do they merge up their private copies?
Like the naming scheme above:
$merge filename@@A filename@@B
>
> If you say your system is not intended for concurrent development, I
> think it is not worth doing. And from what I can see, you're
> building in restrictions that would make concurrent development
> hard.
??????????????????????????
? Where have I said this ?
??????????????????????????
> > Using the same system
> > (labelization) to identify both individual version and configuration
> > is also a neat idea.
>
> It is neat, but eventually will become a pain in the neck. You'll
> need a way to come up with a unique label for every checkin, so you
> will inevitably just decide to use incrementing numbers, so pretty
> soon you will end up with files having versions 1, 5, 329, and
> 18473. Ugh.
The first goal of SCM is to physicaly identify your software . This
goal is achieve. After, it's up to you to choose a good naming
convention for labels. And yes, it's neat ;-)
regards,
j.
-- Jerome de Vivie jerome . de - vivie @ wanadoo . fr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/