You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John McNally <jm...@collab.net> on 2003/07/08 03:34:58 UTC
non-release (vendor/developer) tags
Is there a policy in jakarta-commons on tagging the cvs repo?
Here is my situation: I use dbcp in its current HEAD state. It is
stable for my usage. However there is a critical bug and the desire by
developers to rewrite large portions of the code, essentially removing
some code that was added since its last release. In the past when I
have started a refactoring on a codebase that has had a long fairly
stable period, but no release, I add a PRE_SOME_CHANGE type of tag. If
I added such a tag to dbcp should I expect that it will persist
"forever"? In httpd, I see tags that start with the developer name.
Presumably, it is then up to that developer to remove the tag, if they
no longer require it; and others should leave it alone. Are such
developer tags acceptable in jakarta-commons? Would non-release tags be
better marked by the developer that made it, or should more generic
names be used?
If I were to create a PRE_SOME_CHANGE tag, I would be inclined to leave
it for posterity, in the event someone else had started depending on it,
and would expect others to leave it alone as well. But if it was
JMCNALLY_1, I would remove it as soon as I was able to move to a
released state and it would give others the ability to contact me if
they wondered if the tag had outlived its usefulness.
john mcnally
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Permanently Removing directories from the CVS Tree
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Great, thanks!
Martin Cooper wrote:
>On Tue, 8 Jul 2003, Mark R. Diggory wrote:
>
>
>
>>We've got a directory that got accidentally created in the math sandbox
>>project, it has no contents and is blocking cvsignore from working
>>properly, is there a policy or proceedure for getting empty directories
>>permantently removed from the cvs tree?
>>
>>
>
>I'm not aware of any policy, but when the directory is empty, I see no
>harm in removing it, especially in the sandbox.
>
>
>
>>The directory is "target" at:
>>http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/math/target
>>
>>
>
>Deleted.
>
>--
>Martin Cooper
>
>
>
>
>>thanks,
>>Mark
>>
>>--
>>Mark Diggory
>>Software Developer
>>Harvard MIT Data Center
>>http://www.hmdc.harvard.edu
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Permanently Removing directories from the CVS Tree
Posted by Martin Cooper <ma...@apache.org>.
On Tue, 8 Jul 2003, Mark R. Diggory wrote:
> We've got a directory that got accidentally created in the math sandbox
> project, it has no contents and is blocking cvsignore from working
> properly, is there a policy or proceedure for getting empty directories
> permantently removed from the cvs tree?
I'm not aware of any policy, but when the directory is empty, I see no
harm in removing it, especially in the sandbox.
>
> The directory is "target" at:
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/math/target
Deleted.
--
Martin Cooper
>
> thanks,
> Mark
>
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Permanently Removing directories from the CVS Tree
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
We've got a directory that got accidentally created in the math sandbox
project, it has no contents and is blocking cvsignore from working
properly, is there a policy or proceedure for getting empty directories
permantently removed from the cvs tree?
The directory is "target" at:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/math/target
thanks,
Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: non-release (vendor/developer) tags
Posted by John McNally <jm...@collab.net>.
It is possible, unless disallowed by the cvs admin. It can be used as a
way of managing a release as well as cleaning up a mistake. In some
environments it may be more difficult to freeze development on a branch
or the release is just not suppose to include everything on the branch.
A release team may create a temporary tag, so that it is not confused
with an actual release, they then move the tag around during testing and
when ready, the official release tag is created and the temporary tag is
removed. That might not be the best explanation, but anyway it is
possible and has uses whether or not such a uses would be considered
best practice I'm not sure.
john mcnally
On Mon, 2003-07-07 at 19:43, David Graham wrote:
> I don't see any problem either but I think a generic name is preferable.
> Can you actually "untag" the code? I thought once it was tagged it was
> there forever.
>
> David
>
>
> --- "Craig R. McClanahan" <cr...@apache.org> wrote:
> > I don't see aany problem with non-release tags like this.
> >
> > Craig
> >
> > On Mon, 7 Jul 2003, John McNally wrote:
> >
> > > Date: 07 Jul 2003 18:34:58 -0700
> > > From: John McNally <jm...@collab.net>
> > > Reply-To: Jakarta Commons Developers List
> > <co...@jakarta.apache.org>
> > > To: commons-dev@jakarta.apache.org
> > > Subject: non-release (vendor/developer) tags
> > >
> > > Is there a policy in jakarta-commons on tagging the cvs repo?
> > > Here is my situation: I use dbcp in its current HEAD state. It is
> > > stable for my usage. However there is a critical bug and the desire
> > by
> > > developers to rewrite large portions of the code, essentially removing
> > > some code that was added since its last release. In the past when I
> > > have started a refactoring on a codebase that has had a long fairly
> > > stable period, but no release, I add a PRE_SOME_CHANGE type of tag.
> > If
> > > I added such a tag to dbcp should I expect that it will persist
> > > "forever"? In httpd, I see tags that start with the developer name.
> > > Presumably, it is then up to that developer to remove the tag, if they
> > > no longer require it; and others should leave it alone. Are such
> > > developer tags acceptable in jakarta-commons? Would non-release tags
> > be
> > > better marked by the developer that made it, or should more generic
> > > names be used?
> > >
> > > If I were to create a PRE_SOME_CHANGE tag, I would be inclined to
> > leave
> > > it for posterity, in the event someone else had started depending on
> > it,
> > > and would expect others to leave it alone as well. But if it was
> > > JMCNALLY_1, I would remove it as soon as I was able to move to a
> > > released state and it would give others the ability to contact me if
> > > they wondered if the tag had outlived its usefulness.
> > >
> > > john mcnally
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: non-release (vendor/developer) tags
Posted by David Graham <gr...@yahoo.com>.
I don't see any problem either but I think a generic name is preferable.
Can you actually "untag" the code? I thought once it was tagged it was
there forever.
David
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
> I don't see aany problem with non-release tags like this.
>
> Craig
>
> On Mon, 7 Jul 2003, John McNally wrote:
>
> > Date: 07 Jul 2003 18:34:58 -0700
> > From: John McNally <jm...@collab.net>
> > Reply-To: Jakarta Commons Developers List
> <co...@jakarta.apache.org>
> > To: commons-dev@jakarta.apache.org
> > Subject: non-release (vendor/developer) tags
> >
> > Is there a policy in jakarta-commons on tagging the cvs repo?
> > Here is my situation: I use dbcp in its current HEAD state. It is
> > stable for my usage. However there is a critical bug and the desire
> by
> > developers to rewrite large portions of the code, essentially removing
> > some code that was added since its last release. In the past when I
> > have started a refactoring on a codebase that has had a long fairly
> > stable period, but no release, I add a PRE_SOME_CHANGE type of tag.
> If
> > I added such a tag to dbcp should I expect that it will persist
> > "forever"? In httpd, I see tags that start with the developer name.
> > Presumably, it is then up to that developer to remove the tag, if they
> > no longer require it; and others should leave it alone. Are such
> > developer tags acceptable in jakarta-commons? Would non-release tags
> be
> > better marked by the developer that made it, or should more generic
> > names be used?
> >
> > If I were to create a PRE_SOME_CHANGE tag, I would be inclined to
> leave
> > it for posterity, in the event someone else had started depending on
> it,
> > and would expect others to leave it alone as well. But if it was
> > JMCNALLY_1, I would remove it as soon as I was able to move to a
> > released state and it would give others the ability to contact me if
> > they wondered if the tag had outlived its usefulness.
> >
> > john mcnally
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: non-release (vendor/developer) tags
Posted by "Craig R. McClanahan" <cr...@apache.org>.
I don't see aany problem with non-release tags like this.
Craig
On Mon, 7 Jul 2003, John McNally wrote:
> Date: 07 Jul 2003 18:34:58 -0700
> From: John McNally <jm...@collab.net>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: non-release (vendor/developer) tags
>
> Is there a policy in jakarta-commons on tagging the cvs repo?
> Here is my situation: I use dbcp in its current HEAD state. It is
> stable for my usage. However there is a critical bug and the desire by
> developers to rewrite large portions of the code, essentially removing
> some code that was added since its last release. In the past when I
> have started a refactoring on a codebase that has had a long fairly
> stable period, but no release, I add a PRE_SOME_CHANGE type of tag. If
> I added such a tag to dbcp should I expect that it will persist
> "forever"? In httpd, I see tags that start with the developer name.
> Presumably, it is then up to that developer to remove the tag, if they
> no longer require it; and others should leave it alone. Are such
> developer tags acceptable in jakarta-commons? Would non-release tags be
> better marked by the developer that made it, or should more generic
> names be used?
>
> If I were to create a PRE_SOME_CHANGE tag, I would be inclined to leave
> it for posterity, in the event someone else had started depending on it,
> and would expect others to leave it alone as well. But if it was
> JMCNALLY_1, I would remove it as soon as I was able to move to a
> released state and it would give others the ability to contact me if
> they wondered if the tag had outlived its usefulness.
>
> john mcnally
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: non-release (vendor/developer) tags
Posted by Martin Cooper <ma...@apache.org>.
I don't see a problem with non-release tags. This is effectively the same
as what the Struts team does when we tag our Commons dependencies prior
to a milestone release.
My preference would be not to have JMCNALLY or MARTINC tags, but rather
have tags that are meaningful to others. Your PRE_SOME_CHANGE tag would
fall into the latter category, assuming the actual name reflected the
nature of the subsequent changes.
--
Martin Cooper
On Mon, 7 Jul 2003, John McNally wrote:
> Is there a policy in jakarta-commons on tagging the cvs repo?
> Here is my situation: I use dbcp in its current HEAD state. It is
> stable for my usage. However there is a critical bug and the desire by
> developers to rewrite large portions of the code, essentially removing
> some code that was added since its last release. In the past when I
> have started a refactoring on a codebase that has had a long fairly
> stable period, but no release, I add a PRE_SOME_CHANGE type of tag. If
> I added such a tag to dbcp should I expect that it will persist
> "forever"? In httpd, I see tags that start with the developer name.
> Presumably, it is then up to that developer to remove the tag, if they
> no longer require it; and others should leave it alone. Are such
> developer tags acceptable in jakarta-commons? Would non-release tags be
> better marked by the developer that made it, or should more generic
> names be used?
>
> If I were to create a PRE_SOME_CHANGE tag, I would be inclined to leave
> it for posterity, in the event someone else had started depending on it,
> and would expect others to leave it alone as well. But if it was
> JMCNALLY_1, I would remove it as soon as I was able to move to a
> released state and it would give others the ability to contact me if
> they wondered if the tag had outlived its usefulness.
>
> john mcnally
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org