Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
"Gerhard Fiedler" <lists at connectionbrazil.com> wrote in message
news:h8sabyjvzfiu$.126yv530dtf1b$.dlg at 40tude.net...
> > If another developer is working on a different function or fix why would
> > they use the same tag, they wouldn't, so there is no common tag and
there is
> > no reason for the tag to move, so there is no problem. Example Bob is
> > working on bug 4343 in the bug database so he tags his files with
FIX4343,
> > Jan is working on feature 5653 in the requirements database so she tags
her
> > files with FUNC5653, even if the two overlap there is no common tag.
When it
> > comes down to promoting the two who ever got done first will have to be
> > promoted first or they may have to be promoted together.
>
> I'm not sure I understand you here completely... But for what I
understand,
> Bo's comments still hold. Cvs is based on differences between successive
> revisions.
What in essense, SCM system isn't?
>
> Let's say Bob and Jan start working off revision 1.45 of a file, which at
> that time was the HEAD revision of that file on the main branch.
>
> Then Bob commits his changes. Since nobody has committed anything yet,
HEAD
> is still 1.45. So Bob's commit creates revision 1.46, which now becomes
> HEAD. He tags it with FIX4343. But this doesn't help much in order to find
> out what Bob has changed. To know that, you'd have to have a tag before
and
> a tag after. Only the tag after doesn't give you the information what has
> changed.
There is a tag that describes what happened before Bob's changes, in fact
there are probably 2.
One is the previous build tag something like BLD145 (could be at 1.45 or
1.44 or ??) and or a previous function or fix tag.
What is most important is the differences between the build previous to
Bob's changes and the point at which Bob completed his changes and this is
garrenteed to be bounded by the previous build tag and Bob's fix tag.
>
> Anyway, now Jan is ready to commit. When she tries to commit, the cvs
> client will complain that her file is out of date -- because she's still
on
> revision 1.45, but the current HEAD revision is 1.46 (Bob's commit). She
> needs to run an update, which will merge Bob's changes into her file. She
> needs to review the merge, make sure everything is still working, and then
> commit. If she tags that now with FUNC5653, this tag will include whatever
> has been done for the FIX4343 (since that has been committed before).
>
> Especially if Jan had tagged the files before her fix to get a difference
> before/after, this difference would include Bob's FIX4343 change.
It is expected that Jan would have to update to include Bob's changes before
commiting, as I said before Jan's FUNC5653 becomes dependent on Bob's
FIX4343 because Bob checked in first.
>
>
> If I understand your procedure correctly, it was created around some
> specific features of your version control system. I think you won't find
> many that support this way of doing things (again, if I understood it
> correctly). It seems to go contrary to what most version control systems I
> know do.
>
Nope no specific feature just labels in MKS and MKS is built on RCS. The
only real difference between MKS labels and CVS tags is CVS is a bit more
restrictive on when you can apply a tag and the whole sticky tag thing.
> If you really are interested in cvs/cvsnt, I suggest that you read up on
> how it works, and on how other people work with it. Then you look at the
> /requirements/ of your company (not the current /procedures/), and try to
> come up with a procedure to fit the requirements with what cvs has to
> offer. I suspect it will be a different procedure than what you have now.
>
I've read just about everything out there and it seems like we could
impliment our proccedure in CVS with the exception of it being a 2 step
process to commit and tag, which isn't really a barrier just an annoyance. I
think the sticky tag thing could get in the way but it could be worked
around.
I will admit that I've been working on the assumption that managment
wouldn't let me change our proceedure, since then I've discovered that they
are open to some changes in proceedure, so I'm exploring new possiblities.
The whole bug ID concept could be used except for a couple of restrictions:
1. It assumes that you want to use it to merge between 2 branches. It seems
like one would want to update to the latest revision on a given branch with
a given bug id.
2. Can't apply bug id after a revision is commited, I know that I forget
things like this far too often to not have this feature.
3. Can't tag based on bug id, seems like a pretty usefull thing.
4. Can't remove a bug id from from a revision, again mistakes do happen, or
there are those times thing just have to be moved around.
If I understand the way other people use CVS there are at least a couple of
things that conflict with the requirments I've been given.
1. Management wants to have control over what goes into each offical build
(i.e. builds built by the test group, and potentially used by the rest of
engineering) and they want that control at the function or fix level that
I've been describing. From what I've read, other users of CVS create new a
official build by just taging and possibly branching the HEAD, not much
control there.
2. Maybe I'm missing something here but it seems that CVS developers are
expected to work at the HEAD of the entire project, which in our experience
leads to developers sandboxes being polluted with unfinished and possibly
non-functional work from other developers, and they waste a lot of time
getting other peoples crap to work.
Now problem #1 could be solved in CVS by branching at the start of the
release cycle to create a release branch. Development could continue on the
trunk with functions and fixes being identified via the bugid feature or a
tag. New official builds would then be produced by merging completed and
approved functions and fixes into the release branch then tagging the tip of
the release branch. You would need a mechanisim to ensure that when you
bring a function or fix to the release branch your only bring approved
functions. For example given the three files foo.c, bar.c and blah.h below
merging just FIX24 into the release branch would not be allowed because it
would bring along part of FIX23, which could break the release build.
foo.c
rev 1.2 BUGID=FIX23
rev 1.3 : BUGID=FIX23
rev 1.4 : BUGID=FIX24
bar.c
rev 1.5 : BUGID=FIX24
rev 1.6 : BUGID=FIX24
blah.h
rev 1.1 : BUGID=FIX23
rev 1.2 : BUGID=FIX23
However, how would you identify where on the development branch (i.e. trunk)
the different release candidate builds are so that developers can base there
work on a known good working build? Since you can't checkout, update, or tag
by bugid (without doing some sort of merge) there is no easy way to do this
that I can see.
Another solution could be that all functions and fixes could be on there own
branches which are then merged back into the TRUNK when they are ready to go
into a release candidate. Developers commiting to the trunk would not be
allowed, except in rare cases. This seems like an awfull lot of branching
and merging, and the potential to merge things out of order greater.
However, as I understand it this is close to the model used by ClearCase.
Plus this method may give the developers the ability to checkout a sandbox
based on a stable build with the ability to merge in whatever additional
functions and fixes they want or need.
I'm open to more suggestions.
Matt S.
> Gerhard