Re: better changeset tracking
| From: | Rasmus Lerdorf | Date: | Wed, 30 May 2007 14:57:23 +0000 |
| Subject: | Re: better changeset tracking | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-29956@lists.php.net to get a copy of this message | ||
Jani Taskinen wrote:
> On Wed, 2007-05-30 at 01:29 -0700, Rasmus Lerdorf wrote:
>> Well, the problem is that if the work involved to do this is in any way
>> CVS-specific, it will be throw-away work once we move away from CVS,
>> which is inevitable. What we don't know at this point is the lifespan
>> of CVS. I'm unmotivated to do anything with SVN with the major 1.5
>
> You keep repeating "inevitable", but exactly what is the "inevitable"
> here? AFAIK, CVS works fine: don't fix if it isn't broken!
> I'd like to here the (real) reasons why the switch would be beneficial
> for project like PHP.
I keep repeating? I have said that exactly once.
The problem with CVS is that nobody is working on improving it. There
are a lot of features in modern source control systems that we will
never see in CVS. Not that subversion has them yet either, but with
version 1.5 they are moving in the right direction.
Some of the things that would directly benefit the project:
- Easier to handle changesets
this can be hacked onto CVS, but nobody has done this yet for
cvs.php.net
- Sparse checkouts (1.5)
Ever try checking out phpweb and get stuck waiting for all the
distribution tarballs to download or having your disk fill up
because of it?
- Better performance
- Atomic commits
- Merge tracking (1.5)
Andi mentioned that our process wouldn't benefit from this, but
I think that is a case of our process being set up to match the
limitation of the tool and not necessarily because it is the
best way to do things. With merge tracking you get repeated
merges and the ability to cherry pick changes from one branch
without messing up the previous or subsequent merges.
- svn blame, status and diff --summarize are all quite handy
- It would be nice to have real rename and move support to avoid the
manual repository hacks
- Better integration with external tools
The big negatives are of course:
- We lose real tagging
- We will lose commit history on some files
- Our less technical users will be confused for a while
- The development process will be affected
-Rasmus