> This seems to work, but it is easy to forget which part of the repo
> you are pointed at. As a result one can easily find themselves
> attempting to check into the clean tag, which is actually allowed by
> default, ugh.
This is why I suggest to disallow comitting to /tags/clean (or /tags
altogether). I guess on of the the pre-commit hooks can easily do that.
Sasha
(Moving the discussion back to the mailing list -- was carelesss last time)
Adam Messinger wrote on 05/27/2005 2:32 PM:
> Sasha,
>
> Thanks for the response. So far the best approximation I've found
> for this involves using an svn tag to represent the last clean build
> and then using the svn switch command to change where the working
> copy comes from. So you would do this:
>
> svn co repo/project/tags/clean project/
> // edit files in project/
> svn switch repo/project/trunk project/
> svn checkin project/
> svn switch repo/project/tags/clean project/
> // start doing more editing
>
> This seems to work, but it is easy to forget which part of the repo
> you are pointed at. As a result one can easily find themselves
> attempting to check into the clean tag, which is actually allowed by
> default, ugh.
>
> Cheers!
>
> Adam
>
> On May 27, 2005, at 2:24 PM, sasha.ov@gmail.com wrote:
>
>> Adam --
>>
>> I am thinking about implementing something like this in the future,
>> Here is a rough idea:
>>
>> 1. "svn info" and retrieve "Revision: <revision>" from the output
>> 2. "svn delete svn://server/repo/tags/lastbuilt"
>> 3. "svn cp --revision <revision> svn://server/repo/trunk svn://
>> server/repo/tags/lastbuilt"
>>
>> The problems here are that A) I don't know what happens when the
>> developer does an update on
>> /lastbuilt after it was re-created B) In order for the developer to
>> commit to the main trunk
>> they need to switch, like "svn switch svn://server/repo/trunk". You
>> need also to
>> disallow comitting to /lastbuilt because if they forget to switch
>> and commit to /lastbuilt
>> their modifications can be lost (very hard to find).
>>
>> There might be a better solution involving "svn merge" but it seems
>> to be more complicated.
>>
>> Regards,
>> Sasha
>>
>> Adam Messinger wrote on 05/27/2005 10:03 AM:
>>
>>> I'm experimenting with using svn instead of p4. However I'm
>>> having difficulty figuring out how to migrate one bit of our
>>> workflow to svn.
>>> Currently we set a p4 label (which is just a symbolic alias to a
>>> revision number) from Cruise Control each time a clean build
>>> occurs in the trunk. This label moves several times an hour and
>>> typically trails the head change by a handful of changes.
>>> Developers who don't want to risk grabbing changes that break the
>>> build in their working copy update at the label rather than at the
>>> head. Developers then make their changes, test, and checkin the
>>> change (sometimes an additional update and resolve is required if
>>> the same files have changed in the working copy and in the
>>> repository between the label and head).
>>> Is there a way to accomplish a similar workflow using svn? I've
>>> looked back through the mailing list archives and it seems that
>>> whenever the topic of p4 labels comes up people suggest using svn
>>> tags. I've looked at this, but I can't see how to make it work
>>> here because one would need to checkout from a tag, but then
>>> checkin to the trunk. I apologize if I'm missing something
>>> obvious here.
>>> Cheers!
>>> Adam
>>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 28 00:15:00 2005