On Fri, 2006-06-30 at 20:52, Bob Proulx wrote:
> > > Tags in CVS are often used like cheap branches. What you describe
> > > looks like a subversion branch.
> >
> > Yes - I want a branch that represents exactly the testing workspace
> > but I only want it to appear to anyone else when testing is complete.
>
> Changes in the subversion repository are atomic. But updates to a
> working copy are not and will take time to checkout. Is atomicity
> during a checkout important?
No, I think that is basically hopeless when the changes need
to be propagated across a farm of servers anyway. The update
would happen to a staging server followed by running a script
that rsync's to the production servers.
> > Tags don't actually have any effect on the file versioning and moving
> > them doesn't affect any history. It only affects which file versions
> > are identified by that tag.
>
> Negative. We are talking past each other. Because tags in cvs do
> affect file versioning and moving them definitely changes history.
File versioning always happens in CVS independently from tags.
The tag is just a convenient name for a particular set of them.
You can always get any version of any file without the tag.
> > > > That sounds reasonable. Is there a way to rename existing tags? In
> > > > the CVS scheme I would use rtag to change the RELEASE tag to
> > > > RELEASE-1, etc. for a few downrev versions, then add a new RELEASE.
>
> If yesterday I cvs checkout -rRELEASE I get a set of files identified
> by the RELEASE tag. Then you bless the RELEASE tag either on new
> files or on later versions of files to identify a new contour with
> RELEASE, moving that floating tag to a new set of files. Then
> tomorrow I cvs checkout -rRELEASE and I will get a different set of
> files than I got yesterday.
>
> The tag RELEASE now identifies something different then it did before.
> Files identified by RELEASE have changed. And cvs does not record the
> history of the movement of tags and so looking at cvs log will not
> show me when the RELEASE tag was applied nor when it was moved to a
> new version. The two trees both checked out with RELEASE are
> different and I have no way to tell when this occurred nor even
> exactly what changes occurred.
RELEASE always identifies the set of files you applied it to,
which is exactly why you apply it. In my example, I always
floated 3 tags 'up' a position so I maintained my own
history of where prior tags had been (RELEASE-1 moves up
to RELEASE before RELEASE moves to the versions in the
testing workspace). I've never actually backed out a whole
release anyway but it is nice to know it would be possible.
Occasionally old versions of individual files are needed
but the file history is always there independently from
the tags.
> Using a floating tag like that is common in cvs. This is why I call
> it a "cheap branch". It is maintaining a branch-like behavior that
> file versions can change from moment to moment with different file
> revisions being identified by it. By my reasoning if you can get a
> different result at different times from the same command then it has
> branch-like behavior.
The testing workspace is sort-of a branch. Changes can happen
there and be committed back while the head of the repository
continues to change. Then the tag identifies the versions
as they exist in the workspace. However, with a set of fast
changing web sites you might push updates to production daily
or more often and rarely if ever back anything out, so the
history of groupings in the testing set isn't all that
useful.
> > I think this is leading to using 2 branches - one for the test snapshot,
> > then one for the release after someone blesses it.
>
> That seems perfectly workable. I think it requires more merging
> because you will need to merge changes from the trunk onto each
> branch. But that should still work fine.
Wouldn't you work in the test branch if changes are needed
and then merge to production from there?
> This is where we diverge. In CVS a tag can move. Or you can choose
> never to move it.
If you wanted an 'unchanging history' method in CVS, I suppose
you could script a way to get the list of files/versions as
they exist in the test workspace, then check out exactly that
list instead of using a tag as a reference to the set. That
would be repeatable at any future time.
> That is the *other* behavior of cvs tags. LATEST would move. But
> when LATEST moves the history of where it pointed to previously is
> lost. This is not supported by cvs. But svn uses directory trees for
> tags and versions tree operations.
I'm not particularly interested in the history of the testing
branch - I just need a workspace to gather the versions that
will go to production, perhaps with a few changes. Is it
possible to delete it, or is it cheap enough to ignore?
> > If the tester finds a problem with one file, with CVS he could fix
> > it and commit that file or ask the developer to do it, then update
> > that file into his workspace before the rtag operation.
>
> There are different ways to do that change. On a branch? On the main
> trunk and then merge back into the branch? On the main trunk and then
> just move the tag to the file on the main trunk? In that last case
> what if the main trunk has other incompatible changes already?
>
> Could you outline that part in a little more detail?
There are a couple of likely possibilities. One is a small change
that the tester would do himself which I'd expect to be done in the
testing branch, the other would involve notifying the developer who
committed the broken version that it needs to be fixed, which
would probably be done on the trunk and merged in. And there
will be the rare case where a quick fix needed to make this
snapshot work should not be on the trunk because you will do
it the right way there later.
> > If you can't do individual file changes in subversion,
>
> I don't quite agree with that statement.
OK, I'm certainly not an expert or I wouldn't be asking...
> > > NOW=$(date +%F-%T)
> > > svn copy -rGOODVERSION $URL/trunk $URL/tags/release-$NOW
> > > svn checkout $URL/branch/latest .
> >
> > I don't want anything else that has been committed to the trunk
> > at this point other than what the tester might have changed or
> > requested to have changed. Isn't this operation going to pick
> > up unrelated new work?
>
> No. Because I specified the -rGOODVERSION it will select specifically
> that revision of the trunk. Developers may have committed changes on
> top of that version but this will copy it based on the specified
> version. New commits will not be copied to the tag.
OK, but when we ask the developer to fix that one thing, how
do we get it into the trunk, the test branch, and the test
workspace without picking up other unrelated changes that
may now be on the trunk?
> The process model I was proposing was an unstable trunk where all
> development happens on the main trunk. Then a stable branch where
> known good snapshots of the trunk are captured with a tag.
>
> A disadvantage is that the main trunk must periodically work and
> become a good version so that it can be captured. Or it is an
> advantage. This is where different people will have different
> opinions.
I don't think it is right for this case. There will be times
where there will be work in progress on the trunk that should
not be in production but a change is needed from the snapshot
taken for the test step. We need a place where that change
can be made.
> I consider it an advantage. One of the premises of agile code
> development is that the project should be always kept in a releasable
> state.
I think that's impractical for our case. I want work-in-progress
to live in the repository so it is always backed up and people
are less likely to make conflicting changes. And sometimes
updates need to go to production before the whole trunk
is snapshot-ready.
> Therefore I consider this normal when working in an agile
> development environment. If the code is always releasable and always
> passing all tests then it is easy to periodically make a release from
> the main trunk. Or as in the case above pull changes from the main
> trunk into the release branch.
That would be a good approach for something more monolithic than
a set of web sites with lots of different parts updated by
different people.
--
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 Sat Jul 1 06:28:08 2006