Re: Questions and possible patch

Jim,

These sounds like very nice patches.

I know that once in a while people ask about exactly the functionality 
that you've described for the build off of a label feature.  Can you 
walk me through how you guys will use this feature?  This would be just 
for my benefit so that I can learn more about the different practices 
that people use.  Right now I imagine that your development team at some 
point says that all the code is complete, so maybe the lead developer 
labels the code as "complete."  Then, you have an Anthill project set up 
to build the "complete" label.  Is this correct thus far?  If so, then 
how do nightly builds and continuous integration builds play into this?

On the disable CVS style label, why don't we just move the code that 
makes the label safe for CVS into the CVS adapter?  We have the 
makeTagFromVersion(String) method in the RA interface but for some 
reason (an oversight on our part) we do not use that method to make the 
version label safe for CVS, instead we make the label safe in the 
ProfileAdapter.label() method, which gets used by all the adapters.  So 
what I propose on this issue is that we move lines 375 and 376 of 
ProfileRepositoryAdapter into the 
CVSRepositoryAdapter.makeTagFromVersion() method.  I believe that if we 
do that, then we will not need the extra property in the PerforceAdapter 
screen.  Would that work for you?

I think the label prefix is a nice enhancement.  I'm trying to think of 
how we could make this apply to more than just Perforce, but I think 
we'll just have to add this feature to each RA one by one.

Is it possible for you to enter each one of these as a separate issue in 
bugzilla, each with its own zip file?  If it's too much work, then don't 
worry about it.

Also, can you make sure that you patches are relative to the latest 
source.  I know that we just made some changes to the Perforce adapter, 
specifically how it works with views and labels.

Let me know what you think,

--Maciej


Jim Ray wrote:
>>/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 <mailto:...@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] <mailto:[email protected]>>
> 
>