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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 5 05:59:32 2006