[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: cvs "grouping" feature

From: Brouwer, Marcel
Subject: RE: cvs "grouping" feature
Date: Fri, 2 Sep 2005 08:31:50 +0200

I can't follow the complete discussion. But if I'm right, there are some 
for functionality to support 'functional' grouping the way I described before?!

If it's not here at the moment,what should be the best way to handle my problem?
>We are working with software releases which will be released at a certain 
>point in time. And it is not clear 
>if al change request will be in it. (Some not finished jet, not passed 
>acceptance test, or QC)
>But also to propagate some change requests from development to test before the 
>complete release will 

I saw in a newsgroup someone who handled this by: Every developer had to put 
the change request number in the commit info every time they commit. 
By using some fancy scripting he can determine which files belong to each other.
Than at delivery time for the release they make a manual 'build' by tagging al 
files in changerequest which where passed test/QC etc.

I think this is error prone and time-consuming. There should be a better way.!!!

-----Oorspronkelijk bericht-----
Van: Russ Sherk [mailto:address@hidden
Verzonden: woensdag 31 augustus 2005 18:17
Aan: Derek Price
CC: info-cvs; Brouwer, Marcel; Frank Hemer
Onderwerp: Re: cvs "grouping" feature

On 8/31/05, Derek Price <address@hidden> wrote:
> Russ Sherk wrote:
> >On 8/31/05, Derek Price <address@hidden> wrote:
> >
> >
> >>Russ Sherk wrote:
> >>
> >>
> >>
> >>>>Can the new functionality be extended to allow a 'commit session'?
> >>>>-----
> >>>>cvs ci-startsession (create commitid cid1)
> >>>>cvs ci filea  (cid1)
> >>>>cvs ci /sompe/other/sandbox/fileb (cid1)
> >>>>cvs ci-endsession (close commitid cid1)
> >>>>----
> >>>>
> >>>>
> >>Why not just: `cvs ci filea /some/other/sandbox/fileb'?
> >>
> >>
> >
> >To allow for 'functional' groupings.  It seems though that it would
> >only be a convenience function that keeps track of committed files and
> >applies the same tag to them (instead of the user keeping track and
> >tagging them manually).
> >
> >Just a thought.
> >
> >
> The command I suggested should do the same thing.  Also, it seems to me
> that you could create your 'functional' grouping using `cvs tag -r
> commitid1 functag; cvs tag -r commitid2 functag' easily enough after the
> two commits, at least once the newtags branch is completed and merged.
> I only object because auto-tagging individual commits is a commonly
> requested feature and I don't really want to blur the concept by
> confusing commitids with 'functional' tags, as I thought their use would
> be mutually-exclusive as you presented it.  I suppose if someone wanted
> to code a -t <tag> option or the like for commit that auto-tagged the

Yep.  This did come to mind.  In general it would behave like the -m
option except it'd have to properly handle existing tags (i.e. need to
add -F option to ci...) as well as apply tags instead of log messages.

> committed files with the specified additional tag, that might also
> produce something like the functionality you are requesting.
> Okay, I also object because I have no plans to code this without
> funding.  If you thought it was useful enough for CVS to autogenerate an
> additional 'functional' tag via your suggested transactions or the like,
> and were to code it and contribute the patch yourself, it might be taken
> more seriously.  :)

Hmmm...  so if I paid you, you'd code it up?  I've often wondered how
the funding portion of these 'open source' projects work.  But that is
another story for another time I guess.  I'll take a look at the code
and see what I can come up with.  Assuming it should be for 1.12


> Regards,
> Derek
> --
> Derek R. Price
> CVS Solutions Architect
> Ximbiot <>
> v: +1 717.579.6168
> f: +1 717.234.3125
> <mailto:address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]