On Tue, Nov 21, 2006 at 12:46:14PM -0600, Les Mikesell wrote:
> On Tue, 2006-11-21 at 11:05 -0500, John Rouillard wrote:
>
> > Sort of. The only workspace where they all must be checked
> > out/assembled is the one that is used to distribute the files to the
> > end computers. This is a read only workspace except in critical
> > conditions so will never be used for a checkin.
> >
> > Some users (e.g. me) do keep an entire trunk working copy around, but
> > it is not in a publishable state (in work data is present). I could
> > just check out the subset of the repo I need and use it for these
> > changes as some people do in which case I would never have the entire
> > workspace checked out at all. (I probably should work this way since
> > I have accidentally checked in some files before their time 8-().
>
> Do non-working or untested copies ever need to be committed at all?
Yes. The distribution mechanism to the test hosts is used for testing.
The only way it gets its data is from subversion to allow rollback of
a broken test deployment. All changes via config are mediated through
svn.
> If each person's changes can stay in their own workspace until
> finalized everyone should be able to just commit their changes
> and everyone else can update to them when convenient or required.
Yup it would be easier, but it doesn't work that way.
> > Usually the workflow is more like:
> >
> > I checkout the ldap sub-tree under the trunk, make a change and
> > check it back in. Dave reviews my change (from the repository, not
> > a working copy) decides it's good and promotes it to production. In
> > CVS this was a couple of commands to move the PRODUCTION label and
> > place a new permanent label for each reviewed file. It was very
> > straight forward.
>
> Did you have some other reason for the switch to subversion? I
> agree that CVS is more convenient for some things - particularly for
> individual files or where the things you want together don't fall on
> directory boundaries.
Real versioning on directories is the primary. CVS just didn't handle
this well and as you scale from 1 to 10 to 1000 hosts and change your
processes the directory structure often changes to accommodate.
Also atomic commits were a biggie as I have cleaned up the mess left
over from partly committed changes in CVS. Not fun.
> > The distribution mechanism runs and updates to get the files that
> > were promoted to the production tree (in CVS a label/tag on the
> > trunk). So my change now exists as a small change in the production
> > system. Of the 400+ files in there, I only changed 1 file and I
> > never needed (nor did anybody else) to check out all 400+ files.
>
> If the files were arranged in subdirectories matching the people that
> need them, that's all you'd have to check out/commit.
The files are arranged by functional groups (files likely to be
changed together or that do cross reference each other) not user
access rights as multiple people need access to some files and not
others. The access rights are handled by pre-commit scripts.
> > [Les] You can commit yours to the trunk where they will accumulate
> > [Les] a change history and copy to a tag where they are easy to
> > [Les] find. Who decides that they are verified and that the set
> > [Les] is complete?
> >
> > It should be somebody other than me. The problem is having to copy the
> > handful of files at a differing revisions to the tag that is a clone
> > of a prior tag except for these few files. This is just messy and
> > error prone.
>
> If the current versions are always committed/merged to the head of
> the trunk or a production release branch along with the tag copy, you
> would never have to worry about revision numbers.
Hmm, not quite seeing what you mean here. The working/test versions
are always committed to the head of the trunk. Then some version of
files that are committed to the trunk are deemed ready for production.
What I have tested is to:
delete the file from the production branch/tag and
svn copy -r REV http://repo/trunk/file http://.../production/file
the problem is that I have no history of the REV's of file that were
used. Well that isn't exactly true I think with SVN 1.4 I can now use
peg revisions with the log keyword but it's a pain.
That's what I am doing now, but I loose all the history in the
production copy on every delete/copy operation from trunk to
production. Well it's in the log comment but....
> The trick is just to keep the non-production work elsewhere.
Well the non-production work lives on the trunk.
> How hard would it be to change the concept of labeling production to
> merging to the production branch?
It's painful to have to keep the pristine working copies around and
perform the merges from different revisions all over the place. I
described the workflow before 7 or so steps of which a number are
fragile (well maybe the switch can be eliminated). Then repeat 10
times a day with all the hassles of merging
figuring out what the ancestors are for a given file etc.
I am looking at using svnmerge to take the easily screwed up parts out
of it, but I am having issues getting it to merge files at different
revisions and track that successfully. Then again I haven't spent much
time with it.
> Then the tag only matters if you need to backtrack and don't want
> to check the logs.
Yup. Makes rollback easier as I can actually use a single repository
revision to unmerge from production.
> Or, you could push
> the untested changes into a different subdirectory and have the
> person blessing them copy to the real locations if that is easier
> that merging.
Again requires multiple pristine working copies. I consider that
dangerous and really hate the idea of going repository -> working copy
-> repository for this sort of stuff. Somebody forgets to svn up the
working copy before merging and wipes out work. Plus it requires
re-entering the log messages on the production tree to tell when a
particular fix entered production as opposed to a label that just
piggybacks on the data from the trunk.
> > [Les] But if these files
> > [Les] really don't have anything to do with each other what's the
> > [Les] point of putting them together and then fighting over which
> > [Les] version is which?
> >
> > Because all the files are pushed/pulled to the end systems. So they
> > are not coupled in the classic sense of an application, but they do
> > have (implicit) interrelationships when they are actually
> > deployed. When deployed they are all configuring a box for it's
> > purpose.
> >
> > It is this configuration (for many systems) that is the real object I
> > need to version control. It is made up of small components that can be
> > individually tested and deployed, but the whole set is what needs to
> > be released. Think of doing 5-10 (or more) software releases a day.
>
> There is obviously a massive scripted structure around this thing.
Hardly massive but I take your point.
> Why don't you just modify it to maintain the list of file revisions
> you want in a file in the head of the repository? Then you could
> check out the head and run script to update to the backrev's listed.
Yup except the SVN update times suck hard. Having to do a separate
update -r for every one of 400+ files in the tree is really bad. Hence
my using a production branch to execute the update all in one svn
invocation. Even on a single branch it still takes almost a minute to
do a full update last time I checked.
Oh well looks like I will have to roll my own transfer tools to get
SVN to work in this model. Now we know why people can make careers out
of tools like clearcase 8-).
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 21 22:06:48 2006