Intro and questions

[pe...@arm.com]

My name is Peter Westlake, and I work in the Development Systems part of
ARM, looking after builds and source control. I am looking into possible
replacements for CVS, and Subversion seems like a natural candidate. It has
the usual advantages of free software, and it will be familiar to our CVS
users. It also uses one of my favourite algorithms, "shadow paging" (the
"bubble-up" method of updating the repository atomically), and it all seems
very well thought out.

I have some questions. Starting with the easy ones:

About the way revision numbers apply to the whole repository:
- don't they increase incredibly quickly?
- isn't it confusing when a file's revision changes even though it itself
has not?

Then the hard ones:

- what support can Subversion offer for distributed working? We have
offices all over the place, and the network connections are not always as
fast or as reliable as we could wish.

- the main problem area of CVS that Subversion does not (yet) appear to
improve upon is modules. CVS modules are badly broken, in that you have to
hack around in the internal files of the repository to set them up, and the
module structure is not versioned. So if I make a module include another,
and check out the parent module from a date before I did that, I get the
included module. What scope is there for putting a fully versioned module
mechanism into Subversion? I get the impression that it ought not to be
that difficult if approached in the right way. Such an implementation would
have to support recursive operations, e.g. branching a module and all its
sub-modules. Of course, this isn't always what you want, so there would
have to be two ways to define a sub-module: one where the sub-module would
be thought of as "part of" the parent module, and branched with it, and one
where it would be thought of as "referenced by" or "linked to" the parent,
so it would not be branched. Instead, both branches of the parent module
would point to the same sub-module. There is also the orthogonal
distinction of static vs dynamic sub-modules, which corresponds roughly to
using a tag or a branch. If a module contains a static link to another,
then any checkout of the parent module will get the same revision of the
sub-module. With a dynamic link, it gets the tip. If the parent module is
checked out from some time in the past, it would get the revision of the
dynamic module current at that time.

Have I explained all this in a way that makes sense? If so, do you think
that the design of Subversion would permit these functions to be added
cleanly?

Peter.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Intro and questions

["Mark C. Chu-Carroll" <mc...@watson.ibm.com>]

On 25 Jul 2001 15:37:49 +0000, Justus Pendleton wrote:
> peter.westlake@arm.com writes: 
> 
> > one where the sub-module would  be thought of as "part of" the parent 
> > module, and branched with it
> 
> Why don't subdirectories suffice for this? 

Because there's a distinct version history for the subproject.

It's really most useful for avoiding the "frequent merge" problem
of project-oriented versioning. That is, every time anyone changes
anything, anywhere in a large project, you need to do a merge before
a checkin.

If you have a large number of programmers working on a system, that
gets to be extremely irritating - every time you do a merge, you need
to recheck the system to make sure nothing broke, and then someone
else did a checkin while you were testing, so you need to merge again...

With subprojects, you checkout a complete version of the system.
Then you work on your subproject. You do checkins and merges against
your small piece of the project, which are only visible to other people
working on the subproject. Then the subproject reaches a stable point,
and you check the subproject into the parent project.

The changes to the master parent project become less frequent, and
people worry less about interfering with one another; plus you get the
additional advantage that you can put in tentative changes for other
workers on the subproject to evaluate, without worrying about breaking
the build for everyone working on the system.

If you've got a good solid branch system, then you're pretty close to
being able to do subprojects. There's just a little bit of
infrastructure
that needs to be added, and it works. (Think of a subproject as a
branch where you're only allowed to checkin changes to a specified 
subset of the system.)

	-Mark

--

Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center 
<mc...@watson.ibm.com>
*** The Synedra project:
http://domino.research.ibm.com/synedra/synedra.nsf


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Intro and questions

[Justus Pendleton <su...@ryoohki.net>]

peter.westlake@arm.com writes: 

> one where the sub-module would  be thought of as "part of" the parent 
> module, and branched with it

Why don't subdirectories suffice for this? 

Justus 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Intro and questions

[Greg Stein <gs...@lyra.org>]

On Wed, Jul 25, 2001 at 02:59:13PM +0100, peter.westlake@arm.com wrote:
>...
> About the way revision numbers apply to the whole repository:
> - don't they increase incredibly quickly?

Yup. No reason to assume it is a problem, tho.

> - isn't it confusing when a file's revision changes even though it itself
> has not?

Shouldn't be. Revision numbers refer to *overall* changes, and users know
that. Looking at the log of a file will only show that file's changes. Part
of the "confusion" would simply be from users who associate revision numbers
with *files* rather than overall changes. But even for those with an
expectation or history, the change in outlook isn't that difficult.

> - what support can Subversion offer for distributed working? We have
> offices all over the place, and the network connections are not always as
> fast or as reliable as we could wish.

Not for 1.0. We're worrying about that later.

> - the main problem area of CVS that Subversion does not (yet) appear to
> improve upon is modules.

We've talked about it, but will deal with the issues after M3. We have some
hard work to do, and this can be deferred. I know a lot of people have taken
the time to respond to this, chewing up cycles :-), but we'll really be
spending the time on this later.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Intro and questions

["Mark C. Chu-Carroll" <mc...@watson.ibm.com>]

On 25 Jul 2001 14:59:13 +0100, peter.westlake@arm.com wrote:
> My name is Peter Westlake, and I work in the Development Systems part of
> ARM, looking after builds and source control. I am looking into possible
> replacements for CVS, and Subversion seems like a natural candidate. It has
> the usual advantages of free software, and it will be familiar to our CVS
> users. It also uses one of my favourite algorithms, "shadow paging" (the
> "bubble-up" method of updating the repository atomically), and it all seems
> very well thought out.
> 
> I have some questions. Starting with the easy ones:
> 
> About the way revision numbers apply to the whole repository:
> - don't they increase incredibly quickly?

From experience with other project-based versioning systems, they don't
increase all that quickly - but what's more important is that you look
at version numbers a *lot* less. In a project-based system, you're
always looking at *consistent project versions*, and you don't worry
much about the version number. You pretty much use either the current
version, or some particular past version that was marked with a label. 

> - isn't it confusing when a file's revision changes even though it itself
> has not?

It doesn't. There's a mindset change when you start using
project-oriented
versioning. You don't think in terms of "file revisions" - it's *project
versions*. And just because the project version changed doesn't mean
that
you're necessarily dealing with a different file version. It's *not* the
case that every time you create a new project version, it automatically
creates a new revision of every file. File revisions continue to happen
in essentially the same what that they would in a file-based system; but
you *never* look at file revision numbers. 

> Then the hard ones:
> 
> - what support can Subversion offer for distributed working? We have
> offices all over the place, and the network connections are not always as
> fast or as reliable as we could wish.

Subversion is building WebDAV support, which will allow remote access
with a much more rational protocol than CVS. I suspect that the WebDAV
remote access will be much more robust in the face of slow or unreliable
network connections that CVS ever was.

> - the main problem area of CVS that Subversion does not (yet) appear to
> improve upon is modules. CVS modules are badly broken, in that you have to
> hack around in the internal files of the repository to set them up, and the
> module structure is not versioned. So if I make a module include another,
> and check out the parent module from a date before I did that, I get the
> included module. What scope is there for putting a fully versioned module
> mechanism into Subversion? I get the impression that it ought not to be
> that difficult if approached in the right way. Such an implementation would
> have to support recursive operations, e.g. branching a module and all its
> sub-modules. Of course, this isn't always what you want, so there would
> have to be two ways to define a sub-module: one where the sub-module would
> be thought of as "part of" the parent module, and branched with it, and one
> where it would be thought of as "referenced by" or "linked to" the parent,
> so it would not be branched. Instead, both branches of the parent module
> would point to the same sub-module. There is also the orthogonal
> distinction of static vs dynamic sub-modules, which corresponds roughly to
> using a tag or a branch. If a module contains a static link to another,
> then any checkout of the parent module will get the same revision of the
> sub-module. With a dynamic link, it gets the tip. If the parent module is
> checked out from some time in the past, it would get the revision of the
> dynamic module current at that time.

I don't know what subversion is doing here. I'm working on a different
system which I hope to open-source this fall, and which does handle
subprojects (what you're calling "modules") correctly. We've spent a lot
of time thinking about how to get this kind of thing correct with
respect
to the tradeoffs between strong consistency guarantees and flexibility.
It turns out to not be that hard to do. Once our system becomes open,
then the subversion team will be more than welcome to browse our system,
see what we did, and then implement it for Subversion. There's
absolutely nothing
about Subversion that seems to be incompatible with the subproject
notion, so I don't think that it should be any problem for them to do.

	-Mark Chu-Carroll




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Intro and questions

[kf...@collab.net]

<pe...@arm.com> writes:
> - the main problem area of CVS that Subversion does not (yet) appear to
> improve upon is modules. CVS modules are badly broken, in that you have to
> hack around in the internal files of the repository to set them up, and the
> module structure is not versioned. So if I make a module include another,
> and check out the parent module from a date before I did that, I get the
> included module. What scope is there for putting a fully versioned module
> mechanism into Subversion? I get the impression that it ought not to be
> that difficult if approached in the right way. Such an implementation would
> have to support recursive operations, e.g. branching a module and all its
> sub-modules. Of course, this isn't always what you want, so there would
> have to be two ways to define a sub-module: one where the sub-module would
> be thought of as "part of" the parent module, and branched with it, and one
> where it would be thought of as "referenced by" or "linked to" the parent,
> so it would not be branched. Instead, both branches of the parent module
> would point to the same sub-module. There is also the orthogonal
> distinction of static vs dynamic sub-modules, which corresponds roughly to
> using a tag or a branch. If a module contains a static link to another,
> then any checkout of the parent module will get the same revision of the
> sub-module. With a dynamic link, it gets the tip. If the parent module is
> checked out from some time in the past, it would get the revision of the
> dynamic module current at that time.
> 
> Have I explained all this in a way that makes sense? If so, do you think
> that the design of Subversion would permit these functions to be added
> cleanly?

What you describe is roughly what we have been thinking about for
module support, actually...

This has been discussed informally a bit, iirc, but we haven't got
concrete implementation plans yet, mainly because there's so much else
to work on and modules seem like something to be done over a mature
repository design, rather than early on.

I'm looking forward to stealing^H^H^H^H^H^H^H learning from Mark
Chu-Carroll's modules experience when we get to that point.

I doubt we'll be tackling this anytime in the next few months.  That
could change if someone gets an inspired design and volunteers to do
it, though. :-)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org