On Aug 21, 2007, at 06:04, Jeremy Pereira wrote:
> On 20 Aug 2007, at 17:58, Lucas Stephanou wrote:
>
>> On 8/20/07, Rainer Sokoll wrote:
>>
>>> On Thu, Aug 16, 2007 at 05:14:28PM -0300, Lucas Stephanou wrote:
>>>
>>> > example:
>>> > John is manager of GB subproject, and he decide to make a
>>> package with a
>>> > bugfixes that involves
>>> > GB/sources/PHP/module_b/file1.php
>>> > GB/sources/PHP/module_b/file2.php
>>> > GB/sources/JAVA/module_a/file2.php
>>> > GB/sources/JAVA/module_b/file1.php
>>> > and here come my question, how I can made this using
>>> subversion? how I can
>>> > mark this files to be part of my package.
>>>
>>> You could use a property, for example "svn:belongs_to: GB" or
>>> svn:belongs_to_GB: yes".
>>> On the other side: You already know that all under GB belongs to
>>> GB, so
>>> I don't see your problem. But maybe I got you wrong.
>>
>> thx for you reply,
>> but you loose the point :-)
>>
>> I want a package with just that files, but the full tree of GB is
>> much bigger.
>>
>> I need a way to checout/export and got only files that as marked
>> ( how mark??).
>>
>> in this case I want to package 4 files, ok!.
>> in the zip must be just this files
>> GB/sources/PHP/module_b/file1.php
>> GB/sources/PHP/module_b/file2.php
>> GB/sources/JAVA/module_a/file2.php
>> GB/sources/JAVA/module_b/file1.php
>> why, 'cause this is a upgrade package, when costumer unzip
>> this, it will overwrite just this files in right place.
>>
>> if need more explain, please, ask me for that!
>
> Subversion is a versioned file system and it doesn't have tags in
> the CVS sense. The usual way to implement tag like behaviour is to
> create a directory in the repository named after the tag and copy
> the project into it. In your case you'd only be copying the files
> for the upgrade, not the whole project.
>
> I normally organise my repository like this:
>
> /project_a/trunk - ongoing development code
> /project_a/branches - branches for new/experimental stuff
> /project_a/tags/1.0
> /project_a/tags/1.1
> /project_a/tags/2.0
> etc
>
> (Actually I take advantage of the flexibility of subversion and I
> actually call the tags directory "releases" but I'll stick with the
> usual terminology here.)
>
> Each subdirectory of tags is created as follows:
>
> svn cp <url>/project_a/trunk <url>/project_a/tags/<release number>
>
> That copies the whole project. You only want some files so you'll
> have to use svn mkdir to create the directory structure under the
> tags directory and svn cp the files in individually. You'll also
> probably want to do it all in a working copy in order to make the
> patch creation appear atomic.
>
> Pretty soon you are going to get bored of that so you'll figure out
> a way to automate it. If your users are on Unix, you can make the
> tag by svn copying the whole project as I do and then run svn diff
> against the previous release and the new release. The output is in
> unified diff format and is suitable for input to patch(1) (I think:
> others on the list can correct me, if I'm wrong).
I'll add to this:
I agree that the Subversion way to deal with this issue, Lucas, is to
make a tag of each version that you release. (And in Subversion,
"making a tag" is just making a copy of the trunk to the tags
directory with a particular name.) This is normal procedure when
releasing a version of a software program whose source is in Subversion.
Note that I would not attempt to create tags that only contain the
changed files. a) that's difficult to do, and b) that's really not
what a "tag" is according to the Subversion definition. A "tag"
should be a complete copy of your project at a given time.
So if you have tags of your complete project both at the old version
and now at the new version, then your question just becomes: how do I
get just the files that differ between two tags? And that question
has been asked on the list many times before, for example here's a
good thread to read:
http://svn.haxx.se/users/archive-2005-02/0420.shtml
That's a few years old, and in the mean time, the option they're
speculating about in that thread has been implemented, and is called
"svn diff --summarize". I believe this is new as of Subversion 1.4?
So you can say...
svn diff --summarize $URL/tags/old-version $URL/tags/new-version
...and it will print out the list of files that are different between
the two versions. Then you just write a small script which exports
each of those items from the repository to a local directory, ready
for zipping up. Since the question comes up so often, maybe someone
has already written that script for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 21 13:37:30 2007