httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kean Johnston <...@sco.com>
Subject Re: [PROPOSAL] Move httpd to the subversion repository
Date Mon, 15 Mar 2004 12:47:02 GMT
> your going to be forcing people to install some other piece of software.
> while this might be fine for a lot of people, some won't or can't.
> Some IDE's don't have SVN support yet, and some people have to deal with 
> sysadmins who think redhat 5.2 is acceptable work environment to develop 
> with.
> 
> I'm -0.5 on the issue overall. I can't see what benefit it will give 
> httpd overall at this stage.

While I can't cast a vote, I'd like to agree with Mr. Holsman and offer 
a few comments for those that do vote to think about.

I understand that SVN is the bright shiny new toy in the toybox and a 
lot of people have worked very hard to make it work, and its good. But 
at the same time, one should be careful of falling into the "when you 
have a new hammer everything looks like a nail" trap.

Before deciding on something as important as switching your working, 
well-known-with-warts-and-all revision control system to a new one there 
are implementation details beyond just the tool interface that are 
worthy of consideration. For example, in CVS, every file under revision 
control is backed by a filesystem object. In SVN all files are managed 
in a (much smaller) set of filesystem objects as managed by Berkeley DB. 
This implies fundamental limitations not present in the current system. 
Think large files. Sure LFS is not likely to be an issue on your servers 
but it might be. Its worth thinging about. Whereas currently you would 
be restricted to 2Gb per filesystem object in a repository, you are now 
*potentially* restricted to 2Gb per repository. Maybe BerkeleyDB works 
around this. Maybe it doesn't. Maybe you just dont care and you make LFS 
a server requirement. Its worth investigating. It also has considerable 
backup and restore consequences. In the current system, if a repository 
file goes bad, you can restore just that file. With the SVN approach of 
you happend to get a bad sector in the middle of your repository you may 
have to restore the entire thing. Its not a huge deal I know but still, 
I'm just making sure you consider the issue, even if just to dismiss it 
as a non-issue.

Are you sure that things like keyword expansion will work as they 
currently do? They probably will do but again, it should be carefully 
considered. Are there perhaps custom keywords such as $Apache$ or the 
like that would need to be rolled into the local version of SVN? If 
there are custom keywords *can* they be implemented at the repository 
server level or would such expansion be taken care of at the client 
level (which would imply that all clients would need to be patched 
accordingly)?

The original proposal stated that full history will be preserved. As I 
recall from the svn dev list the cvs2svn conversion process has been 
plagued with difficulties. Are all the issues resolved? If you do make 
such a move is there an auditing mechanism in place that you can run to 
guarantee that all history has been preserved? Historical data is of 
inestimable value and if there is even the slightest chance that some of 
it could be lost or become less accessible these are risks that need to 
be understood and clearly agreed upon as being acceptable losses.

If there are a specific list of problems that frequently hamper 
developers that such a move would address, it is worth drawing up that 
list and debating the relative importance of each problem. Moving just 
because the tool is available is likely to cause some unforseen 
headaches down the road.

Having said all that, I fully acknowledge that svn is a huge step 
forwards from cvs in many many ways, but at the end of the day, there is 
no such thing as a magic bullet, and you will really just be exchanging 
one set of problems for another.

Just my $0.02.

Kean


Mime
View raw message