Re: Questions and possible patch
Jim Ray <[email protected]> 10 Jan 2003 13:23:50 -0700
| Newsgroups | gmane.comp.java.anthill.devel |
|---|---|
| Message-ID | <[email protected]> |
--=-6toPCw0l5Jt+jFiRVRAe Content-Type: text/plain Content-Transfer-Encoding: 7bit > Can you provide a little more detail on the building off a label patch? > I ask because the patches that are the easiest to integrate and > therefore the one that will be integrated first are the ones that treat > all source repositories equally. This does not mean that you can't have > a Perforce specific patch. The sync to Label basically adds a label field to the PerforceRepositoryAdapter properties that you can sync to. So the command it runs looks like: p4 sync -f //view/...@label_name or p4 sync -f @label_name The changes ended up being pretty small except for the shell script for the unix_perforce profile. This is useful for my company doing release builds through Anthill. We use a generic label that designates that code is ready for release and then sync to that label for the build. > You can totally have a patch like the > "disable CVS style tagging" that applies only to Perforce. But, I'm > worried about the "building off label for Perforce" patch since it has > the potential to affect the build screen which is used by all projects > (regardless of repository). > Disable CVS style tagging I implemented as a text field that looks for yes or y on in the label method of the perforce repository adapter and if it is not present do the normal replace on the tags. > Basically, if your patch is going to be repository specific, then that > is ok as long as all changes are local to the repository adapter. If > your patch is going to include changes beyond the repository adapter > (such as the build screen), then we need to make sure that all the other > repository adapters can handle that change as well. > I also added to the PerforceRepositoryAdapter a field name label prefix that can add a prefix to the normal label/tag. Since Perforce doesn't have the same concept about labels I thought that allowing the prefix would allow for more fine grain control of label names. For example, version file has the contents 2.2.0.1 the label in perforce shows up as just that with a letter in front or something by default. So with the prefix set to LM- The label shows up as LM-2.2.0.1 All of my changes have happend in the perforce profiles or in the PerforceRepositoryAdapter. -- Jim Ray <[email protected]> --=-6toPCw0l5Jt+jFiRVRAe Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/1.1.6"> </HEAD> <BODY> <BLOCKQUOTE TYPE=CITE> <PRE><FONT COLOR="#737373" SIZE="3"><I>Can you provide a little more detail on the building off a label patch? I ask because the patches that are the easiest to integrate and therefore the one that will be integrated first are the ones that treat all source repositories equally. This does not mean that you can't have a Perforce specific patch. </I></FONT></PRE> </BLOCKQUOTE> <FONT SIZE="3"><BR> The sync to Label basically adds a label field to the PerforceRepositoryAdapter properties that you can sync to. So the command it runs looks like:<BR> <BR> <BR> p4 sync -f //view/</FONT><A HREF="mailto:...@label_name"><FONT SIZE="3">...@label_name</FONT></A> or<BR> p4 sync -f @label_name<BR> <BR> <FONT SIZE="3"><BR> The changes ended up being pretty small except for the shell script for the unix_perforce profile. <BR> <BR> This is useful for my company doing release builds through Anthill. We use a generic label that designates that code is ready for release and then sync to that label for the build. <BR> </FONT><BR> <BLOCKQUOTE TYPE=CITE> <PRE><FONT COLOR="#737373" SIZE="3"><I>You can totally have a patch like the "disable CVS style tagging" that applies only to Perforce. But, I'm worried about the "building off label for Perforce" patch since it has the potential to affect the build screen which is used by all projects (regardless of repository). </I></FONT></PRE> </BLOCKQUOTE> <FONT SIZE="3">Disable CVS style tagging I implemented as a text field that looks for yes or y on in the<BR> label method of the perforce repository adapter and if it is not present do the <BR> normal replace on the tags. <BR> </FONT><BR> <BLOCKQUOTE TYPE=CITE> <PRE><FONT COLOR="#737373" SIZE="3"><I>Basically, if your patch is going to be repository specific, then that is ok as long as all changes are local to the repository adapter. If your patch is going to include changes beyond the repository adapter (such as the build screen), then we need to make sure that all the other repository adapters can handle that change as well. </I></FONT></PRE> </BLOCKQUOTE> <FONT SIZE="3"><BR> I also added to the PerforceRepositoryAdapter a field name label prefix that can add a <BR> prefix to the normal label/tag. Since Perforce doesn't have the same concept about labels<BR> I thought that allowing the prefix would allow for more fine grain control of label names. <BR> <BR> For example,<BR> <BR> version file has the contents 2.2.0.1<BR> <BR> the label in perforce shows up as just that with a letter in front or something by default.<BR> <BR> So with the prefix set to LM-<BR> <BR> The label shows up as LM-2.2.0.1<BR> <BR> All of my changes have happend in the perforce profiles or in the PerforceRepositoryAdapter. <BR> <BR> </FONT><BR> <PRE><TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> -- <BR> Jim Ray <<A HREF="mailto:[email protected]">[email protected]</A>> </TD> </TR> </TABLE> </PRE> </BODY> </HTML> --=-6toPCw0l5Jt+jFiRVRAe--