Chris.Fouts@qimonda.com wrote:
>>
>>>>> My bad! CC has a config spec that provides a way to pick
>> and choose,
>>>>> or "filter" what files can be in a build. What's neat about
>>>> it, I can
>>>>> mix and match any trunked, tagged, or branched files in the
>>>> repos. For
>>>>> example, I can
>>>>>
>>>>> element foo.c /b_R1/2
>>>>> element * /b_R1/latest
>>>>> element * /main/latest
>>>>>
>>>>> This means, in this order...
>>>>> 1. Use v2 of foo.c from the b_R1 branch 2. Use b_R1 branch for the
>>>>> rest of the files,
>>>>> if the files are on that branch
>>>>> 3. Use the /main/latest version of the rest of
>>>>> files
>>>>>
>>>>> If I remove the second line, I'll ignore the b_R1 branch,
>> except for
>>>>> foo.c /b_R1/2, ON THE FLY.
>>>>>
>>>>> I may have added the top line because I found a problem with the
>>>>> /b_R1/latest version of foo.c (say v3), so I elected to use v2
>>>>> instead.
>>>>>
>>>>> I can "commit" changes using config specs.
>>>> Creating a Complex Tag
>>>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.htm
>>>> l#svn.branchmerge.tags.mkcomplex
>>>>
>>>> It is probably more effort to set up with Subversion, but doable.
>>>>
>>> Thanks for the link, but I read it and don't quite follow. Please
>>> explain how complex tags can be act like a "confg spec?"
>>>
>>> - How can I use it to checkout the files I need, and then work with
>>> those files?
>> Start by checking out the version with the largest portion of
>> the files you want - probably the head of the trunk or a
>> branch. Then selectively
>> update the parts you want to earlier revisions. You could
>> do that in a script or batch file if you plan to repeat it,
>> but you'd probably be better off branching if you expect to
>> re-use this combination.
>
> Can I mix/match trunked/branched/tagged files in my workspace?
> For example, will this work?
> svn co //repos/trunk myws
> svn co //repos/branch/dir1 myws
> svn co //repos/tags/dir2/file1 myws
Not exactly. Note that it is trivial to 'svnadmin create' a file repo
for testing so you know exactly what to expect. Probably easier than
asking here... You can, at directory levels, 'svn switch' to different
branches and update after the initial checkout. This will automatically
update the working copy directory to match the switched repository and
subsequent commits will go back there. Within a directory you can 'svn
update -r ### file' to force an update to an earlier revision out of the
same repository branch. I don't think you can pull an arbitrary
backrev of a single file from some other branch and maintain versioning
(you could export it and copy where you wanted, of course). Svn likes
to work atomically with directories.
> If I then make changes to a file exclusively in the
> //repos/trunk
> //repos/branch/dir1
> //repos/tags/dir2/file1
> and do an "svn commit", will the changes go in the
> //repos/trunk
> //repos/branch/dir1
> //repos/tags/dir2/file1
> correct?
Switched lower level directories commit back the their corresponding
branches. You can't control it at the file level.
>>> - How can I use it to tag (label?) those files?
>> You can "svn copy" your current working copy to a tag - or to
>> start a new branch. Your working copy does not have to match
>> any existing revision when you do this.
>
> Thanks for the reminder! Say I want to tag my above workspace
> as R1. I expect the R1 tag to be applied to
> the //repos/trunk files
> the //repos/branch/dir1 files
> the //repos/tags/dir2/file1 file
> correct?
Svn tags are not labels applied to existing versions (a long-running
discussion here...). A tag in svn is a 'cheap copy' that gets its own
name and what appears to be a copy of everything included in that tagged
version. It is identical to a branch except for the convention that you
don't commit changes back to it. So, if you copy your working copy to a
tag, you get whatever assortment of files you had assembled there and
you will be able to reproduce that set by checking out the tag.
However, you won't be able to look back from future trunk revisions and
see where that tag was applied.
>>> - How can I use it to then commit the changes?
>> If you branch, you'd just switch to the branch and work
>> normally. What does clearcase do when you commit to something
>> you specified as a backrev of a file?
>>
>
> CC uses the config spec I alluded to for ALL transactions!
> So if I checkout foo.c, it will checkout the b_R1/2 version
> because of my first rule. If I remove that rule, it will
> checkout the b_R1/latest (3 in this case) version. BTW, I'll
> have to add the
> element * CHECKEDOUT
> rule to see my checkout out version of a file first.
But you didn't answer the question of where it sends a commit to a file
you specified as a backrev. Does/should this go to the HEAD?
> This flexibility is one feature I really miss. It factors into
> CC being an "software configuration manager, or SCM" rather than
> just a revision control system. Perforce has a similar feauture,
> but NOT as convenient.
In svn, you would normally assemble the parts you want, copy them to a
branch to hold them together for future work, making tag snapshots for
anything you want to be able to reproduce exactly by name. When/if you
want the changes in this branch to apply elsewhere, you merge them.
Other than the directory vs. file aspect (and the fact you have to track
merge revisions yourself in the current svn) it doesn't sound much more
cumbersome. Just keep in mind that branches are cheap and you can use
them for any assortment of things that you don't want to match trunk
versions.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 30 19:05:57 2007