Jeremy and Ryan,
I appreciate very much your suggestions, and I guess that I'll implement
something like that.
I'm not fully happy :-), but Ok.
On 8/21/07, Ryan Schmidt <subversion-2007b@ryandesign.com> wrote:
>
> 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.
>
>
>
--
Lucas Stephanou
Received on Tue Aug 21 15:20:05 2007