On 10/4/06, Talden <talden@gmail.com> wrote:
> Thanks Troy, that helps convince me that I have a good handle on the
> benefits of Subversion as well. I haven't played with better security
> and I think that linking it to our LDAP would be quite popular.
>
> > Global revisions. Yes, if you come from a CVS (really RCS) world than
> > it is a complete rethink. But in reality it buys you a lot and you
> > lose nothing (in terms of information, maybe in the *presentation* of
> > that information).
>
> Agreed, this isn't a bug, it is definitely a feature that works
> well... The only cost I see here is the loss of visibility as to which
> files are the most busy. It's important to understand that a file
> doesn't have a new revision, the repository does - and the working
> copy number is just an indicator of how up to date you are.
>
> > With global revisions you can do a 'svn log' on a directory and the
> > output makes sense. It isn't just a recursive dump of all the
> > individual files. You have a time-ordered set of all the logs that
> > apply to that directory and it's children. You can actually follow
> > development process.
>
> I use the logs more in my testing of subversion than I ever would in
> CVS just because of the clarity. Atomic renames would help here too
> as would the ability to log the 'futures' of a file/folder - what
> changes have been made, where has it been copied to and how was its
> content modified there.
>
> > Talden mentioned a desire to have 'revision aliases', but what he is
> > describing is 'tags' which you can implement as copies to a 'tags'
> > directory. However, I think the functionality that he is really
> > meaning is the ability to pick some arbitrary point in history (even
> > if you did not have the forethought to 'tag' that set) and pick up a
> > particular version of the code. Without the change set concept you
> > cannot do this efficently. In Subversion you can look through the log
> > output for a particular day, then look around at the commits made
> > during that day to find the SET of changes you are interested in. In
> > CVS you get to go figure that out for every single file that MIGHT be
> > part of the set.
>
> I still think that referring to revision numbers can be cumbersome.
> Using tags is part of the solution for content management but not
> repository management. 'this' revision is the one we were at before
> we did that upgrade or major repository cleanup. It certainly doesn't
> work without changesets.
>
> But yes I definitely didn't stress the benfits of the more flexible
> nature of copying for tags and branches - other than wishing there was
> an explicit means of locking a URL (and sub URLs) from checkins
> without resorting to obscure hooks I think the mechanism works
> brilliantly.
>
> Easy things
> - creating AND removing branches (close branches once they're done)
> - being able to organise tags and branches into logical groups
>
> I've considered
> tags/releases/ -- tags on release, this stuff's in the wild and must
> be supported.
> tags/milestones/ -- tags of completed milestones in development
> branches/dev -- development branches that may make it into trunk
> branches/maintenance/ -- maintainence work for making point releases.
>
> > 'master'
> > 'releases'
> > 'versions'
> > 'source_disk'
> > 'tasks'
>
> very close to the combination I came up with by the sounds of it.
>
> Definitely don't give up, I'll continue to work up a case for
> migration because my experimentation already yielded improvements to
> our process that CVS can't offer without being a burden.
>
> I haven't actually tested the CVS migration tool yet, that sounds like
> fun... Any comments on how easy/hard this process is?
>
> --
> Talden
>
I used the CVS migration tool to convert a RCS repository to
Subversion (RCS->CVS is a trivial move of files up a directory level).
I had some issues with it bailing out because of some formating
issues. There was one file that I ended up just deleting out all the
diff from the RCS file because it wasn't worth the effort to actually
fix it (it was a dead file). I also had to modify the script to just
ignore a revision '1', as that is not a valid RCS revision but it
somehow picked it out of the file. Once I got those things ironed out
then it worked smashingly!
If you using CVS proper you most likely won't have the same issues
because these particular RCS files span more than 10 years and no
fewer than 3 different OSes...they were bound to accumulate some
cruft.
The only real problem I had with the tool was the repository size and
number of revisions. By the time it was all said and done my ~1GB
repository was 2GB with >60000 revs! FSFS just dragged to the point
it was unusable so I had to go with BDB (just too many files in the db
directory). I just read a possible explanation of my repo size
exploding on the dev list: my directory structure. Apparently the
mechanism for storing the directory stuff in the repo is pretty
wasteful and I have a pretty convoluted hierarchy.
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 5 06:17:22 2006