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?
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.
> 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.
> 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.
> [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 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. The trick is
just to keep the non-production work elsewhere. How hard would
it be to change the concept of labeling production to merging to
the production branch? Then the tag only matters if you need to
backtrack and don't want to check the logs. 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.
> [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. 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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 21 19:47:19 2006