[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: subversion module system question

From: Mats Nilsson <mats.nilsson_at_xware.se>
Date: 2002-05-22 16:55:07 CEST

> > Please set me straight. Why is this considered Badness:
> > svn cp -r 1000 /trunk /module-snaps/rev1000
> >
> > while this is not?
> > svn cp -r 1000 /trunk /tags/foobar-1.0
>
> Greg's not saying that using 'svn cp' to create
> tags/branches/cheap-copies is a Badness.
>
> He's saying that it's Bad for a module system to *require* that you
> make a cheap-copy, so that a particular module can always point to
> that location in HEAD.
>
> Instead, a particular module is simply going to point to (revision,
> path) pairs. No copies required.

I had to ask, since I've got the impression that the "a tag is a cheap copy"
mantra has been defended quite intensely. Now during the switch, diff and
module design discussions, all the sudden a quite different idea is
stealthily introduced - that you can refer to a point in space and time
*without* making a copy.

As someone noted a few days ago, modules can be a way of introducing a tag
concept for those uncomfortable with making a copy to mark a tag. Maybe it
would be better to introduce tags as a first class citizen object (something
other than being equal to a cheap copy), if that level of detail is what an
increasing number of commands and features require. Now, only modules will
benefit from sneak-mode tags a.k.a module entries.

I'm not saying that the current suggestion is bad, just that it is diluting
the quite pure filesystem model. And I will still be able to make a cheap
copy tag and refer to its HEAD.

/Mats

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 22 16:56:53 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.