Version Control Upgrade?

LLVMers,

The oversight group has been kicking around the idea of getting a better version control system than CVS. The problem is, we're not quite sure what "better" means. So, we thought we'd ask your opinions.

If you're interested in this topic (and you should be if you're actively developing), please have a look at this site: [http://better-scm.berlios.de/comparison/comparison.html](http://better-scm.berlios.de/comparison/comparison.html#move) It has quite a nice comparison of key features that we're interested in. Some of the features we think are important are shown in the list below. The text in square brackets is the corresponding item at the comparison site.

`

  • [Atomic Commit] - all changed files in a change set get committed or none of them do.
  • [Repository Permissions] - control read/write access to the repository on a per-user basis, preferably allowing the authentication to be hooked into an apache server (like mod_webdav).
  • [Files and Directories Moves or Renames] - make sure moves and renames of both files and directories are tracked as well as edits.
  • [Remote Repository Replication] - ability to clone a repository and “take it with you” so you can commit changes while disconnected from the network. This supports distributed development.
  • [Change set support]. Groups together related changes in multiple files as a logical “change set”. This helps when you need to back out (revert) a change or the change needs to be propagated to another repository because all the related changes are managed as a group.
  • [Tracking Line-wise File History] - basically support stuff like cvs annotate to see who modified the file and when on a line-by-line basis.
    Of the tools available, it seems that only subversion, arch, and monotone are suitable for our purposes. But, we’d love to hear your thoughts; especially if you have first-hand experience with these tools.`

Thanks in advance,

Reid

As the person maintaining a repository and someone using working copies
I much prefer subversion to cvs. I found the move from cvs to subversion
using the cvs2svn tool painless for a repository without tags. I have
not used tags in cvs. Setting svn:eol-style correctly so text checkouts
work to unix and dos can be a pain. Make sure all commiters use
auto-props and you may want to set up
http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl

I not familiar with arch or monotone, but would encourage cvs users to
change to svn.

It was handy that you were still using cvs in the fall semester because
our group used subversion on top of a cvs checkout.

Tom

powerful versionning model (based on SHA-1 signatures), and does not clutter your directories with hidden folders to store versionning info (everything lies in a single folder).

However, Subversion is gaining a wide acceptance as a replacement to CVS, is updated regularly and seems to "work" -- but for people knowing Monotone, Subversion model looks somewhat old. This drawback is really minor, as there are a lot of really cool tools (such as Trac <http://www.edgewall.com/trac/>) which supports SVN and offer very valuable features.

Arch seems only interesting for people who do not have a server on which they can put a Monotone or SVN server, however it's starting to gain some acceptance in the GNU community.

Hope this helps,

  -- Sébastien

I believe subversion does not support "Remote Repository Replication" but svk
does (a modified version of subversion).

After reading the docs for these VCS I don't think there is a clear choice
today. Subversion lacks distributed development. Arch supports distributed
development but forces you to have srcdir != objdir (not necessarily bad, but
i want the choice) and it also has akward commands. Monotone seems very clear
on how it works but lacks a web interface and is unclear how mature it is.

If we don't care about the web interface I suggest we give monotone a try.

Hi everyone,

Reid said:

Of the tools available, it seems that only subversion, arch, and monotone are suitable for our purposes. But, we'd love to hear your thoughts; especially if you have first-hand experience with these tools.

Apart from using CVS as a client (as everyone does), I've only ever used Aegis (previous employer, for ~3 years) and Perforce (the employer before that, though ever since then I've been using the 'free' license for personal stuff.) I've tinkered a bit with some of the shiny new V-C systems.

Well, to put things bluntly, Aegis was a complete and total disaster, while Perforce is the best version control system I've ever used.

Why? Ease of use! Something that isn't mentioned in the version control system comparison Reid mentions. For good reason, no doubt - it is to _some_ extent a subjective thing. However, Perforce has always been an absolute joy to use (I can't stress this enough!!) while Aegis always struck me as more or less designed to _inhibit_ development! (It really does live up to its name on this point, trust me.) The differences can't _all_ be in my head, I hope!

OK, I should at least _try_ to be objective. In contrast to the other VCSs I've used:

  - Perforce _just works_. By this I mean that it only ever takes effort to make it work _differently_, not to make it work _at all_. I don't want to start a flamewar and so won't mention other VCSs that could be contrasted here, but the differences are certainly there. Getting up and running

  - Perforce is _very_ well documented.

  - Perforce is _very_ well supported: should anyone ever need help, Perforce support is incredibly helpful, polite and _eerily_ rapid to respond. At this point I should mention that the VCS comparison says that no support is available for people using Perforce with a free open-source license. This is indeed "the letter of the law", but the reality is that Perforce support tries to help everyone on a best-effort basis. Indeed, the support is so good (I'd never experienced anything like it, and haven't since) that I'm quite sure the guys who write the software are the same guys who answer the emails. It's like LLVM support in that regard. :slight_smile:

  - Perforce is basically idiot-proof. By this I mean that you really need to know what you're doing to lose/mess up data/configuration. Perforce is the closest thing out there to a VCS with an "undo button", as far as I'm aware.

  - Perforce is basically bug-free. For every genuine bug an LLVMer finds in Perforce, I will send him or her a box of chocolates and a handwritten apology. :slight_smile:

It's difficult for me to make a strong case that LLVM should switch to Perforce because I haven't had any problems with the _current_ system, but if we are to switch, I'd recommend Perforce highly. It does everything people ever seem to ask of a VCS, and it's quick, easy and fun to use. Really!

If you has half an hour to burn, visit http://perforce.com , download the software and have a play. You get "the real thing", the only difference is that without a license file, you can't create more than two accounts or workspaces.

Perforce is not the fanciest thing out there, but it's simple and it works well.

  My two yen,

  Duraid

P.S. Perhaps a minor point in this era of 400GB hard disks and 2GHz CPUs, but worth mentioning: Perforce is _FAST_.

Oops, munched a sentence.

where I wrote:

    - Perforce _just works_. By this I mean that it only ever takes effort to make it work _differently_, not to make it work _at all_. I don't want to start a flamewar and so won't mention other VCSs that could be contrasted here, but the differences are certainly there. Getting up and running

I meant to continue:

Getting up and running won't be a problem - while it's different from CVS, it's easy to install and there's ample support for importing CVS archives.

  Duraid

I have used Perforce also and fully agree it's wonderful. The only concern I have is with their license for open source projects. The only gotcha is that it must be renewed annually, and they reserve the right to not renew it (though they say they won't unreasonably deny renewals). Not sure how much this really matters, as Perforce strikes me as being one of those "do no evil" companies.

Duraid Madina wrote:

"Do no evil" has indeed been my experience - they seem to have a couple of people dedicated to overseeing their open-source licensing/relations, and I've never heard of anyone having any problems (can't find anything on the web/in usenet).

The annual renewal isn't as much of a hassle as it sounds, it's basically a matter of sending a one page fax and getting a small license file by email in return. I'm happy to do this on behalf of whoever wants the help, but it really isn't hard.

  Duraid

Jeff Cohen wrote:

OK, so let's say they exercise their right to "not renew a license",
what's our fall-back? If the repository is a binary proprietary format,
(which I'm not sure if it is, please correct me if I'm wrong), how do we
go back to CVS/SVN/Monotone/etc.? Or are we up the proverbial creek?

Misha Brukman wrote:

OK, so let's say they exercise their right to "not renew a license",
what's our fall-back?

Good question.

If the repository is a binary proprietary format,
(which I'm not sure if it is, please correct me if I'm wrong),

It's BerkeleyDB, so the database format is already a little standard, but you'll never have to worry about things at _that_ level because:

how do we
go back to CVS/SVN/Monotone/etc.? Or are we up the proverbial creek?

If your license expires, Perforce doesn't fail, it just reverts to demo mode. All but two users will be able to login and do stuff, and (perhaps) most of the database will become read-only, but you'll always be able to read everything out of the database. You can rest assured Larry McV doesn't work at Perforce: there's no hostage-taking going on here.

  Duraid

Sorry for the noise, but I just wanted to add that there are a ton of translation tools out there. You can find CVS<->Perforce and SVN<->Perforce tools easily enough, and there's a bunch of others. Most of these seem reasonably lossless.

I suspect that most of these tools came about because Perforce and various third parties provide a _bunch_ of APIs:

http://www.perforce.com/perforce/loadsupp.html#api

Microsoft they ain't. :wink:

  Duraid

Reid Spencer wrote:

LLVMers,

The oversight group has been kicking around the idea of getting a better version control system than CVS. The problem is, we're not quite sure what "better" means. So, we thought we'd ask your opinions.

I think before we begin discussing which software to use, we should discuss what is really wrong with CVS (on a day to day basis) and how important it is to fix it (and I apologize if it has been discussed; I just haven't seen it discussed in this thread).

From all the features listed below, file/directory renames and moves are the only missing feature that, to me, warrants changing to another program (and maybe access control, but I haven't looked into that much). Everything else looks like something that would be nice to have, but isn't critical.

So, what exactly are people finding wrong with CVS on a day to day basis, and is it important enough to fix it (fixing it will mean that users will need to download a new program to use the repository, which is a disincentive to using LLVM)?

-- John T.

John,

Here's my list:

1. CVS is slow. Many of the other tools do bi-directional binary deltas
on file changes they are transmitting. This is basically the technology
that makes rsync so fast. CVS doesn't do this. Probably not a big deal
when you're working at UIUC but its CRUCIAL when I'm on the road working
from a hotel or airport wi-fi connection.

2. Related to 1 is diff speed. Subversion, at least, keeps a local copy
of the original (unmodified) version of each file. This makes "svn diff"
instantaneous and doesn't require it to go over the wire. That also
helps make the server more scalable as it off loads work from the
server.

3. CVS doesn't have atomic commits or the notion of a change set. This
has bitten me several times when I'm doing a large commit .. users
update and get .h files out of sync with .cpp files or other
inconsistencies. That never happens with the tools that support atomic
commit (most of them).

4. As you mentioned, file & directory copy/move aren't supported in CVS.
This is a pain at times as I have to contact someone at UIUC to "copy
the ,v file". This bit me over the holidays as no one at UIUC was
available for a day or two. I'm sure you'd all rather not have to deal
with such requests. Chris ends up taking the brunt of these requests.
Many of the other tools support moving and copying files around.

5. CVS doesn't support distributed development well. Tools such as Arch
and Monotone work on a peer-to-peer basis. No one computer is "the
repository". If the CVS server should ever go down (heaven forbid), we'd
all be out of luck. With a peer-to-peer we'd just switch to the most
relevant/up-to-date other repository. This also allows you to take the
repository with you when you travel and still be able to
commit/diff/checkout while not connected to a network. When you get back
you can synchronize with the rest of the world and all your commits will
be rolled into the other repositories. Note that Subversion has limited
support for this via the svn-push and SVN::Mirror utilities. These
essentially keep two repositories in synch. Not sure how scalable that
is.

6. Authorization. Arch/Monotone/Subversion/Perforce all have fine
grained authorization (permission) features. CVS does not. This means we
can't say, "user xyz is given write access only in lib/System" .. we
either give them write access to the whole repository (or a module) or
not at all.

7. Authentication. CVS passwords are notoriously easy to crack and
shipped over the net in plaintext when using pserver. Using SSH would
help but that means giving every developer a login account on the CVS
server. I'm sure UIUC doesn't want to do that. I'm not sure about the
others but Subversion handles this really well via that WebDAV
(Distributed Authoring and Versioning) Apache plug-in. All requests go
via HTTP and the web servers authorization and authentication mechanisms
can be used. This also helps with getting around firewalls.

My $0.02 worth.

Reid.

Hi all,

My 2 cents as well:

Here where I work (The MathWorks), we have hundreds of developers. We
use CVS but we've had to write several thousand lines of Perl to make it
useful to us (through revisions, branching, testing, and integration).
Mercifully, we're planning on going to another system.

In short, CVS doesn't scale well. It also doesn't having good branching
capabilities (or, rather, there are other tools that do branching
better).

I think to rely upon CVS for all important, large-scale projects (like
LLVM will become) is a mistake.

-bw

(Apologies for the top-post...Reid started it ;-P)

Reid Spencer wrote:
} John,
}
} Here's my list:
}
} 1. CVS is slow. Many of the other tools do bi-directional binary deltas
} on file changes they are transmitting. This is basically the technology
} that makes rsync so fast. CVS doesn't do this. Probably not a big deal
} when you're working at UIUC but its CRUCIAL when I'm on the road working
} from a hotel or airport wi-fi connection.
}
} 2. Related to 1 is diff speed. Subversion, at least, keeps a local copy
} of the original (unmodified) version of each file. This makes "svn diff"
} instantaneous and doesn't require it to go over the wire. That also
} helps make the server more scalable as it off loads work from the
} server.
}
} 3. CVS doesn't have atomic commits or the notion of a change set. This
} has bitten me several times when I'm doing a large commit .. users
} update and get .h files out of sync with .cpp files or other
} inconsistencies. That never happens with the tools that support atomic
} commit (most of them).
}
} 4. As you mentioned, file & directory copy/move aren't supported in CVS.
} This is a pain at times as I have to contact someone at UIUC to "copy
} the ,v file". This bit me over the holidays as no one at UIUC was
} available for a day or two. I'm sure you'd all rather not have to deal
} with such requests. Chris ends up taking the brunt of these requests.
} Many of the other tools support moving and copying files around.
}
} 5. CVS doesn't support distributed development well. Tools such as Arch
} and Monotone work on a peer-to-peer basis. No one computer is "the
} repository". If the CVS server should ever go down (heaven forbid), we'd
} all be out of luck. With a peer-to-peer we'd just switch to the most
} relevant/up-to-date other repository. This also allows you to take the
} repository with you when you travel and still be able to
} commit/diff/checkout while not connected to a network. When you get back
} you can synchronize with the rest of the world and all your commits will
} be rolled into the other repositories. Note that Subversion has limited
} support for this via the svn-push and SVN::Mirror utilities. These
} essentially keep two repositories in synch. Not sure how scalable that
} is.
}
} 6. Authorization. Arch/Monotone/Subversion/Perforce all have fine
} grained authorization (permission) features. CVS does not. This means we
} can't say, "user xyz is given write access only in lib/System" .. we
} either give them write access to the whole repository (or a module) or
} not at all.
}
} 7. Authentication. CVS passwords are notoriously easy to crack and
} shipped over the net in plaintext when using pserver. Using SSH would
} help but that means giving every developer a login account on the CVS
} server. I'm sure UIUC doesn't want to do that. I'm not sure about the
} others but Subversion handles this really well via that WebDAV
} (Distributed Authoring and Versioning) Apache plug-in. All requests go
} via HTTP and the web servers authorization and authentication mechanisms
} can be used. This also helps with getting around firewalls.
}
} My $0.02 worth.
}
} Reid.
}
} On Mon, 2005-01-10 at 07:52, John Criswell wrote:
} > Reid Spencer wrote:
} > > LLVMers,
} > >
} > > The oversight group has been kicking around the idea of getting a better
} > > version control system than CVS. The problem is, we're not quite sure
} > > what "better" means. So, we thought we'd ask your opinions.
} >
} > I think before we begin discussing which software to use, we should
} > discuss what is really wrong with CVS (on a day to day basis) and how
} > important it is to fix it (and I apologize if it has been discussed; I
} > just haven't seen it discussed in this thread).
} >
} > From all the features listed below, file/directory renames and moves
} > are the only missing feature that, to me, warrants changing to another
} > program (and maybe access control, but I haven't looked into that much).
} > Everything else looks like something that would be nice to have, but
} > isn't critical.
} >
} > So, what exactly are people finding wrong with CVS on a day to day
} > basis, and is it important enough to fix it (fixing it will mean that
} > users will need to download a new program to use the repository, which
} > is a disincentive to using LLVM)?
} >
} > -- John T.
} >
} > >
} > > If you're interested in this topic (and you should be if you're actively
} > > developing), please have a look at this site:
} > > _http://better-scm.berlios.de/comparison/comparison.html_
} > > <http://better-scm.berlios.de/comparison/comparison.html#move> It has
} > > quite a nice comparison of key features that we're interested in. Some
} > > of the features we think are important are shown in the list below. The
} > > text in square brackets is the corresponding item at the comparison site.
} > >
} > > * [Atomic Commit] - all changed files in a change set get committed
} > > or none of them do.
} > > * [Repository Permissions] - control read/write access to the
} > > repository on a per-user basis, preferably allowing the
} > > authentication to be hooked into an apache server (like mod_webdav).
} > > * [Files and Directories Moves or Renames] - make sure moves and
} > > renames of both files and directories are tracked as well as edits.
} > > * [Remote Repository Replication] - ability to clone a repository
} > > and "take it with you" so you can commit changes while
} > > disconnected from the network. This supports distributed development.
} > > * [Change set support]. Groups together related changes in multiple
} > > files as a logical "change set". This helps when you need to back
} > > out (revert) a change or the change needs to be propagated to
} > > another repository because all the related changes are managed as
} > > a group.
} > > * [Tracking Line-wise File History] - basically support stuff like
} > > cvs annotate to see who modified the file and when on a
} > > line-by-line basis.
} > >
} > >
} > > Of the tools available, it seems that only subversion, arch, and
} > > monotone are suitable for our purposes. But, we'd love to hear your
} > > thoughts; especially if you have first-hand experience with these tools.
} > >
} > > Thanks in advance,
} > >
} > > Reid
} > >
} > >
} > > ------------------------------------------------------------------------
} > >
} > > _______________________________________________
} > > LLVM Developers mailing list
} > > LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
} > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
} >
} > _______________________________________________
} > LLVM Developers mailing list
} > LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
} > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

} _______________________________________________
} LLVM Developers mailing list
} LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
} http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

-bw

I can second this as well also. Many startups start out using cvs because its free (as in beer), and most everyone knows it so little time is wasted setting things up. But as the company grows, cvs becomes a gigantic pain in the ass because it indeed does not scale. Unfortunately, deciding on the VCS to switch to typically also becomes a gigantic pain in the ass, and the larger the company is the more painful it is, so much so that CVS remains in use far longer than is sane.

LLVM is small enough now for CVS to relatively pain-free, but it's not likely to stay that way. And it's better to change now if possible, because the larger LLVM gets and the more developers you have, the more painful it will be to change.

Bill Wendling wrote:

John Criswell wrote:

I think before we begin discussing which software to use, we should discuss what is really wrong with CVS (on a day to day basis) and how important it is to fix it (and I apologize if it has been discussed; I just haven't seen it discussed in this thread).

I turned down the priviledge of having write access to the CVS because of problems with the software. I will describe the root cause of the problem: We are also using CVS locally, and I need to have the LLVM version that we use with our project as part of our CVS so we can tag it when we make releases. Since I also want to sync with the LLVM repository, I have to have two copies of LLVM and manually copy files across. At some point I managed to copy also a CVS directory across and when I tried to check in to our own repository I was actually checking in to the LLVM repository. Luckily I did not have write access.

If I could have write accesss only to the win32 directory tree it would be OK since our local version should match the official version for this part of the tree, and I'm actively working on it and submitting patches to the mailing list. But CVS does not let you have different priviledges for different parts of the source tree (at least I don't know how to set it up).

The other clear deficiency of CVS is that it's not possible to sync the local version with several repositories, I believe the version controls systems which claim to support distributed development support this kind of scenario.

> So, what exactly are people finding wrong with CVS on a day to day
> basis, and is it important enough to fix it (fixing it will mean that
> users will need to download a new program to use the repository, which
> is a disincentive to using LLVM)?

There you have it, this is what I find wrong with CVS on a day to day basis. If it's important enough to fix it is up to the oversight comittee to decide :wink: By the way, the LLVM _users_ are supposed to use the releases which are distributes as tarballs, and have no need to access the repository - The way I see it, it's the contributors who will need to download a new program...

m.

Reid Spencer wrote:

John,

Here's my list:

1. CVS is slow. Many of the other tools do bi-directional binary deltas
on file changes they are transmitting. This is basically the technology
that makes rsync so fast. CVS doesn't do this. Probably not a big deal
when you're working at UIUC but its CRUCIAL when I'm on the road working
from a hotel or airport wi-fi connection.

2. Related to 1 is diff speed. Subversion, at least, keeps a local copy
of the original (unmodified) version of each file. This makes "svn diff"
instantaneous and doesn't require it to go over the wire. That also
helps make the server more scalable as it off loads work from the
server.

3. CVS doesn't have atomic commits or the notion of a change set. This
has bitten me several times when I'm doing a large commit .. users
update and get .h files out of sync with .cpp files or other
inconsistencies. That never happens with the tools that support atomic
commit (most of them).

Okay. I guess this is happening because our CVS server is much slower for you than it is for me, which is why I never have this problem. So this is more important than I thought.

4. As you mentioned, file & directory copy/move aren't supported in CVS.
This is a pain at times as I have to contact someone at UIUC to "copy
the ,v file". This bit me over the holidays as no one at UIUC was
available for a day or two. I'm sure you'd all rather not have to deal
with such requests. Chris ends up taking the brunt of these requests.
Many of the other tools support moving and copying files around.

Agreed. This is a pain, and I forgot that you can't just move stuff around like we can here.

5. CVS doesn't support distributed development well. Tools such as Arch
and Monotone work on a peer-to-peer basis. No one computer is "the
repository". If the CVS server should ever go down (heaven forbid), we'd
all be out of luck. With a peer-to-peer we'd just switch to the most
relevant/up-to-date other repository. This also allows you to take the
repository with you when you travel and still be able to
commit/diff/checkout while not connected to a network. When you get back
you can synchronize with the rest of the world and all your commits will
be rolled into the other repositories. Note that Subversion has limited
support for this via the svn-push and SVN::Mirror utilities. These
essentially keep two repositories in synch. Not sure how scalable that
is.

How important do you (and others) feel this feature is?

6. Authorization. Arch/Monotone/Subversion/Perforce all have fine
grained authorization (permission) features. CVS does not. This means we
can't say, "user xyz is given write access only in lib/System" .. we
either give them write access to the whole repository (or a module) or
not at all.

Agreed, but has this posed a serious enough problem (or do we forsee it becoming a serious problem)? I tend to doubt that we'll be segmenting access to various pieces of the LLVM codebase.

7. Authentication. CVS passwords are notoriously easy to crack and
shipped over the net in plaintext when using pserver. Using SSH would
help but that means giving every developer a login account on the CVS
server. I'm sure UIUC doesn't want to do that. I'm not sure about the
others but Subversion handles this really well via that WebDAV
(Distributed Authoring and Versioning) Apache plug-in. All requests go
via HTTP and the web servers authorization and authentication mechanisms
can be used. This also helps with getting around firewalls.

So far this hasn't posed a serious problem, but as we get more external developers, it will. And the firewall note is also a good point.

Thanks.

-- John T.

The oversight group has been kicking around the idea of getting a better version control system than CVS. The problem is, we're not quite sure what "better" means. So, we thought we'd ask your opinions.

I think before we begin discussing which software to use, we should discuss what is really wrong with CVS (on a day to day basis) and how important it is to fix it (and I apologize if it has been discussed; I just haven't seen it discussed in this thread).

Considering that everyone is managing just fine with cvs, anything discussed about the differences between cvs and *X* is not a show stopper.

-Tanya

Reid Spencer wrote:
>
> 3. CVS doesn't have atomic commits or the notion of a change set. This
> has bitten me several times when I'm doing a large commit .. users
> update and get .h files out of sync with .cpp files or other
> inconsistencies. That never happens with the tools that support atomic
> commit (most of them).

Okay. I guess this is happening because our CVS server is much slower
for you than it is for me, which is why I never have this problem. So
this is more important than I thought.

Yeah, not everyone's on your high-speed network. At some point the
non-UIUC developers will out number the UIUC ones. Network efficiency
and scalability will become very important because data will be coming
from all over the world. We already have patches being submitted from
Germany, Russia, Japan, and probably a few other places I'm not aware
of.

>
> 4. As you mentioned, file & directory copy/move aren't supported in CVS.
> This is a pain at times as I have to contact someone at UIUC to "copy
> the ,v file". This bit me over the holidays as no one at UIUC was
> available for a day or two. I'm sure you'd all rather not have to deal
> with such requests. Chris ends up taking the brunt of these requests.
> Many of the other tools support moving and copying files around.

Agreed. This is a pain, and I forgot that you can't just move stuff
around like we can here.

Yup.

>
> 5. CVS doesn't support distributed development well.

How important do you (and others) feel this feature is?

Right now, its probably not a big deal. When we have significantly more
developers it will become crucial. Not only will it scale better but it
will actually let remote developers be more productive than they can
with a centralized server. I travel on planes a lot and would *LOVE* to
take a copy of the repository with me when I do.

>
> 6. Authorization. Arch/Monotone/Subversion/Perforce all have fine
> grained authorization (permission) features. CVS does not. This means we
> can't say, "user xyz is given write access only in lib/System" .. we
> either give them write access to the whole repository (or a module) or
> not at all.

Agreed, but has this posed a serious enough problem (or do we forsee it
becoming a serious problem)? I tend to doubt that we'll be segmenting
access to various pieces of the LLVM codebase.

I do. As the number of developers grow we'll want to control who has
write access where so that the *developers* can feel safe about what
they can change and what they can't. See Morten's response for a case in
point.

>
> 7. Authentication. CVS passwords are notoriously easy to crack and
> shipped over the net in plaintext when using pserver. Using SSH would
> help but that means giving every developer a login account on the CVS
> server. I'm sure UIUC doesn't want to do that. I'm not sure about the
> others but Subversion handles this really well via that WebDAV
> (Distributed Authoring and Versioning) Apache plug-in. All requests go
> via HTTP and the web servers authorization and authentication mechanisms
> can be used. This also helps with getting around firewalls.

So far this hasn't posed a serious problem, but as we get more external
developers, it will. And the firewall note is also a good point.

Yup. Its not a big deal right now because we're all a friendly bunch and
the community is relatively small. As our numbers start to grow, LLVM
gets a following, and we get more notoriety, there will definitely be
some problems in this area. We can't just trust everyone on the planet
to be good net citizens. Look at what happened to GNU's web site when
they were cracked .. took them months to get it sorted out.

Reid.

Morten Ofstad wrote:

John Criswell wrote:

I think before we begin discussing which software to use, we should discuss what is really wrong with CVS (on a day to day basis) and how important it is to fix it (and I apologize if it has been discussed; I just haven't seen it discussed in this thread).

I turned down the priviledge of having write access to the CVS because of problems with the software. I will describe the root cause of the problem: We are also using CVS locally, and I need to have the LLVM version that we use with our project as part of our CVS so we can tag it when we make releases. Since I also want to sync with the LLVM repository, I have to have two copies of LLVM and manually copy files across. At some point I managed to copy also a CVS directory across and when I tried to check in to our own repository I was actually checking in to the LLVM repository. Luckily I did not have write access.

You might be able to make this process a little easier by using a "vendor" branch in your tree and grabbing our sources using "cvs export."

So, you'd do something like:

cvs -d <our CVS repository> export llvm
cvs -d <your CVS respository> import llvm

... and then merge the LLVM changes from the vendor branch into your mainline branch.

I'm just summarizing the process here, so please see the CVS manual (https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_13.html#SEC103) for all the exact details.

Being able to sync from multiple repositories would still be better, though.
:slight_smile:

If I could have write accesss only to the win32 directory tree it would be OK since our local version should match the official version for this part of the tree, and I'm actively working on it and submitting patches to the mailing list. But CVS does not let you have different priviledges for different parts of the source tree (at least I don't know how to set it up).

The other clear deficiency of CVS is that it's not possible to sync the local version with several repositories, I believe the version controls systems which claim to support distributed development support this kind of scenario.

> So, what exactly are people finding wrong with CVS on a day to day
> basis, and is it important enough to fix it (fixing it will mean that
> users will need to download a new program to use the repository, which
> is a disincentive to using LLVM)?

There you have it, this is what I find wrong with CVS on a day to day basis. If it's important enough to fix it is up to the oversight comittee to decide :wink: By the way, the LLVM _users_ are supposed to use the releases which are distributes as tarballs, and have no need to access the repository - The way I see it, it's the contributors who will need to download a new program...

Actually, all of our bug fixes are only available in CVS (until the next release), so most regular LLVM users will need to update from the repository to get bug fixes, even if they're not committers.

-- John T.