[ On Wednesday, February 16, 2000 at 14:43:26 (-0800), |}avid (opeland wrote: ]
> Subject: Why does CVS treat removed files so specially?
>
> Note that main.c DOES NOT get tagged.
It's not supposed to be.
Tags are used primarily to tag "releases" (i.e. to give a symbolic name
to all of the revis
On Thursday, February 17, 2000 11:43 AM, |}avid (opeland
[SMTP:[EMAIL PROTECTED]] wrote:
> Why does CVS treat removed files in such a special way? To be more
specific,
> consider the following example:
>
> > ls
> CVS/
> blah.c
> main.c
> blah.h
>
> > cvs tag -F some_tag
> T blah.c
> T main.c
>
Essentially, I am version controlling a website. As such files, assets, etc.
get added and removed. On our live site, all files are checked out with the
tag 'live'.
On our development server, users tag files they want to go up to live and a
cron job does periodic cvs updates.
So, from time t
On Thursday, February 17, 2000 2:49 PM, |}avid (opeland
[SMTP:[EMAIL PROTECTED]] wrote:
> Essentially, I am version controlling a website. As such files, assets,
etc.
> get added and removed. On our live site, all files are checked out with
the
> tag 'live'.
>
So you are using a constant 'sl
[ On Wednesday, February 16, 2000 at 17:48:38 (-0800), |}avid (opeland wrote: ]
> Subject: Re: Why does CVS treat removed files so specially?
>
> The problem occurs when doing more sophisticated developemnt. We have
> essentially 5 layers - 1 where developers work, 1 where files ar
>Note that main.c DOES NOT get tagged. Even if you 'cvs tag -F some_tag
main.c'
>it does not get tagged. You can ONLY tag the new (dead) revision, via
>'cvs tag -r 1.2 main.c', which is cumbersome, because not all files in a
source
>tree are on the same revision. You can also do 'cvs tag -r HEA
The difference I have is subtle.
Most everyone on the list defines tagging a file as indicating which files you
want to group into a release.
I define tagging a file as indicating which revisions of files you want to
group into a release. By tagging a dead revision, I am saying "Include the
rem
[ On Thursday, February 17, 2000 at 18:53:05 (-0800), |}avid (opeland wrote: ]
> Subject: Re: Why does CVS treat removed files so specially?
>
> The difference I have is subtle.
>
> Most everyone on the list defines tagging a file as indicating which files you
> want to group i
Not to continue to harp, but:
> No, you're not exactly right and what you're missing is perhaps a
> critical facet that will help your understanding of this issue. "We"
> (i.e. CVS) define tagging to mean which revisions of which files are to
> be grouped together (perhaps for a release, or to m
On Friday, February 18, "|}avid (opeland" wrote:
>
>(To recap, I have a moving tag that I use to indicate which revision of a file
>is in which state of workflow). So, if have dev/stage/live tags, and the dead
>revision is tagged as dev and as stage, but the previous (non-dead) revision is
>tagg
Regarding difficulty using tags with removed files:
How about if instead of deleting a file (and cvs removing it), you modified
it into an empty file and
committed that? Nothing's in the Attic, so tagging is straight-forward.
You could go ahead and remove
the file after all of your tag layers we
[ On Friday, February 18, 2000 at 09:32:06 (-0800), |}avid (opeland wrote: ]
> Subject: Re: Why does CVS treat removed files so specially?
>
> YES. I consider the removal of a file as a new revision of that file. So does
> CVS. I simply want it to apply to concept of tagging, stat
On Saturday, February 19, 2000 6:32 AM, |}avid (opeland
[SMTP:[EMAIL PROTECTED]] wrote:
> Not to continue to harp, but:
>
> > No, you're not exactly right and what you're missing is perhaps a
> > critical facet that will help your understanding of this issue. "We"
> > (i.e. CVS) define tagging t
On 18-Feb-00, 11:32 (CST), "|}avid (opeland" <[EMAIL PROTECTED]> wrote:
> We are NOT doing multiple lines of development, but enacting a process
> WORKFLOW which says that files are in a different state at different
> times. Whether or not the file is present or not doesn't (and
> shouldn't) mat
On Saturday, February 19, 2000 5:41 AM, Greg A. Woods
[SMTP:[EMAIL PROTECTED]] wrote:
> [ On Friday, February 18, 2000 at 17:58:35 (+1300), Chris Cameron wrote:
]
> > Is this a bug? A tag -F will move an existing tag, maybe it should
check
> > in the Attic and remove the tag from any files whi
This solution makes sense to me. I think my argument is probably strenthened
by the fact that 'cvs tag -d <>' in a directory doesn't remove the tag
from removed files.
Thanks!
Dave
On Tue, Feb 22, 2000 at 08:52:41AM +1300, Chris Cameron wrote:
> On Saturday, February 19, 2000 5:41 AM, Greg A.
On Friday, February 18, 2000 3:53 PM, |}avid (opeland
[SMTP:[EMAIL PROTECTED]] wrote:
> The difference I have is subtle.
>
> Most everyone on the list defines tagging a file as indicating which
files you
> want to group into a release.
>
> I define tagging a file as indicating which revisions of
> I think everyone is in violent agreement with you, except that a removed
> file is no longer in the revision.
"The revision" is a misnomer. Checking out via '-r <>' is saying "Get me
all versions of all files with the tag <>. In the case of removed files,
CVS should simply NOT get that file o
18 matches
Mail list logo
