[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: add file and .cvsignore (more or less solve)

From: Philippe Legay <ply_at_acial.fr>
Date: 2007-04-04 15:04:42 CEST

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2007a@ryandesign.com]
Sent: Sun 4/1/2007 11:36 PM
To: Philippe Legay
Cc: users@subversion.tigris.org
Subject: Re: add file and .cvsignore
 
On Apr 1, 2007, at 16:14, Philippe Legay wrote:

> I have received a big projet (2000 files + 8000 gif files).
>
> My idea is :
> 1) tar zxvf bigproject.tgz
> 2) Then check-in check out the files that I will modify for bug
> correction.
>
> So is it or not possible (I read some time yes, some time no and I did
> succeed to do it) to create .cvsignore for the files of
> bigproject.tgz (except for the modified files) that allows me to do
> svn import or svn add without include files from the bigproject.
>
> If yes how must I do that (specific version of the server or the
> client ?) Must the name of .cvsignore file be .cvsignore or can it
> be "myexclusionfilelist" ?
>
> Who is responsable to manage the cvsignore file ? The client or the
> server ?
>
> Thanks for any clear pointer about this problem (that seems to be a
> classical one).

"cvsignore" is a feature of CVS. This is Subversion. It has similar
but different ways of handling the situation.

=> I agree with you, but it is an easy wait to explain my problem. Notice that
the documentation gives example with -F .cvsignore

You have two places where you can tell Subversion that you would like
it to ignore things. One place is the global-ignores directive in
your client's config file (in ~/.subversion/config). This applies to
all working copies you might use on this client.

The other place is the svn:ignore property of every directory in the
repository. You can set svn:ignore of any particular directory, and
then commit that property change. Then all clients that use a working
copy containing that directory will obey those ignore settings for
that directory.

=> Thank, I have not yet noticed the commit to have a ignore file.

See the book:

http://svnbook.red-bean.com/en/1.2/
svn.advanced.props.html#svn.advanced.props.special.ignore

I didn't exactly understand your example with gzipping a tar file,
but if it is your intention to check that gzipped tar file into the
repository, I probably recommend you do not do that. Just check in
the individual files, uncompressed. It is difficult for Subversion to
construct reasonable deltas for compressed data, which means that if
you ever change what's in the compressed data, Subversion may have to
store the entire file in the repository again, rather than being able
to store just a small delta, as it would be able to do if the data
were uncompressed. You may save some space initially by checking in
compressed items, but the more you modify them over time, the more
those space savings will disappear, and then start taking even more
space than it would had you just gone with uncompressed data from the
beginning.

=> I agree with you. The problem is how to build the workspace ? The idea was to
create an empty workspace, then tar zxvf the files that are not in subversion and then
get the subversion files. I think only 50-100 code file will be modified, the 1900 other one
will be in the tar file. So, it is very easy to which files have been modified by company :
the one that are into subversion.

Of course with GIF files they're already internally compressed, so
they're already difficult for Subversion to diff efficiently.

If I've misunderstood the scenario, then by all means please elaborate.

=> My new stategy is :
- create a svn repository for the structure (trunk, branchs, tags)
- then svn co
- then put the modified files + svn add and svn commit
- then get the files from the tar file

As svn commit works only on svn files, I am able to work without managing the 1000 files as cvs:ignore.

In fact, the cvs:ignore -F file does not work. Bug ? Bad usage ?

PHL.
Received on Wed Apr 4 15:05:38 2007

This is an archived mail posted to the Subversion Users mailing list.