You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Pratt <fa...@eastlink.ca> on 2006/12/05 17:33:57 UTC
Advice on co with mac for file type/creator
Hi. When I co from a svn repository on my mac, the file type and creator
are most often empty. I realize I can batch process folders to set types
based on extensions but I am wondering if someone has a better
solution for this - or can advise on how they cope with this. Many thanks.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: pre commit check log
Posted by Brian Krusic <br...@krusic.com>.
Hi Ryan,
The commits are over the internet at several repo locations and are pretty
large as well.
Thanks for the clarification.
Bri-
----- Original Message -----
From: "Ryan Schmidt" <su...@ryandesign.com>
To: "Brian Krusic" <br...@krusic.com>
Cc: <us...@subversion.tigris.org>
Sent: Friday, December 08, 2006 3:23 PM
Subject: Re: pre commit check log
>
> On Dec 8, 2006, at 16:18, Brian Krusic wrote:
>
>> Noticed some behavior using a force log entry pre commit hook.
>>
>> After committing a file with and empty log message, the client is
>> showing that its adding the file before the check is made, then rejects
>> the commit appropriately.
>>
>> I've tried to place this code in the start commit vs the pre commit but
>> it doesn't seem to work that way.
>>
>> Some of our commits take 30 min and so this can be annoying.
>>
>> I feel its normal behavior as there needs to be a commit before a check
>> can be made however I was wondering if anyone can shed some light on
>> this.
>
>
> It is expected that the client needs to transfer the deltas to the server
> before the server can execute the pre-commit hook, but what on earth is
> making your commits take 30 minutes? That's extremely long. Unless you're
> transferring several gigs of data I don't see why that should be.
>
>
>
> --
> To reply to the mailing list, please use your mailer's Reply To All
> function
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.15.15/580 - Release Date: 12/8/2006
> 12:53 PM
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: pre commit check log
Posted by Brian Krusic <br...@krusic.com>.
Forgot to mention that since we are using Tortoise over here, that instead
of doing a pre commit hook, I simply set an attaribute on the folder that
won't allow a user to commit via Tortoise unless they have a comment.
Ofcourse this can be side stepped by command line submits but in those
cases, the pre commit log hook will still be in place.
Just an fyi.
Bri-
Krusic Consulting Inc.
CISSP #51326
----- Original Message -----
From: "Ryan Schmidt" <su...@ryandesign.com>
To: "Brian Krusic" <br...@krusic.com>
Cc: <us...@subversion.tigris.org>
Sent: Friday, December 08, 2006 3:23 PM
Subject: Re: pre commit check log
>
> On Dec 8, 2006, at 16:18, Brian Krusic wrote:
>
>> Noticed some behavior using a force log entry pre commit hook.
>>
>> After committing a file with and empty log message, the client is
>> showing that its adding the file before the check is made, then rejects
>> the commit appropriately.
>>
>> I've tried to place this code in the start commit vs the pre commit but
>> it doesn't seem to work that way.
>>
>> Some of our commits take 30 min and so this can be annoying.
>>
>> I feel its normal behavior as there needs to be a commit before a check
>> can be made however I was wondering if anyone can shed some light on
>> this.
>
>
> It is expected that the client needs to transfer the deltas to the server
> before the server can execute the pre-commit hook, but what on earth is
> making your commits take 30 minutes? That's extremely long. Unless you're
> transferring several gigs of data I don't see why that should be.
>
>
>
> --
> To reply to the mailing list, please use your mailer's Reply To All
> function
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.15.15/580 - Release Date: 12/8/2006
> 12:53 PM
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: pre commit check log
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 8, 2006, at 16:18, Brian Krusic wrote:
> Noticed some behavior using a force log entry pre commit hook.
>
> After committing a file with and empty log message, the client is
> showing that its adding the file before the check is made, then
> rejects the commit appropriately.
>
> I've tried to place this code in the start commit vs the pre commit
> but it doesn't seem to work that way.
>
> Some of our commits take 30 min and so this can be annoying.
>
> I feel its normal behavior as there needs to be a commit before a
> check can be made however I was wondering if anyone can shed some
> light on this.
It is expected that the client needs to transfer the deltas to the
server before the server can execute the pre-commit hook, but what on
earth is making your commits take 30 minutes? That's extremely long.
Unless you're transferring several gigs of data I don't see why that
should be.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
pre commit check log
Posted by Brian Krusic <br...@krusic.com>.
Hi,
Noticed some behavior using a force log entry pre commit hook.
After committing a file with and empty log message, the client is showing
that its adding the file before the check is made, then rejects the commit
appropriately.
I've tried to place this code in the start commit vs the pre commit but it
doesn't seem to work that way.
Some of our commits take 30 min and so this can be annoying.
I feel its normal behavior as there needs to be a commit before a check can
be made however I was wondering if anyone can shed some light on this.
Thanks in advance,
Bri-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Advice on co with mac for file type/creator
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 8, 2006, at 15:19, David Pratt wrote:
> Ryan Schmidt wrote:
>
>> On Dec 5, 2006, at 11:33, David Pratt wrote:
>>
>>> Hi. When I co from a svn repository on my mac, the file type and
>>> creator are most often empty. I realize I can batch process
>>> folders to set types based on extensions but I am wondering if
>>> someone has a better solution for this - or can advise on how
>>> they cope with this. Many thanks.
>>
>> Not really. Subversion does not store type / creator information,
>> or resource forks. It stores the data fork only.
>> On Mac OS X, I have not had to worry about type / creator
>> information in many years; are you sure you have to? For example,
>> if you have a bunch of, say, .txt files, and by default these open
>> into, I don't know, TextEdit maybe, and you would rather use
>> BBEdit, then just click one of the .txt files in the Finder, Get
>> Info on it, in the Open With section select BBEdit, then click the
>> Change All button, and from then on, all .txt files will open into
>> BBEdit. No need to muck with type / creator codes ever again.
>> Does that help you?
>
> Hi Ryan. Thank you for your reply. I do not generally worry about
> creator types in mac either since file extensions are good enough for
> opening applications. The trouble I had was more to do with BBEdit.
> It did not want to do multi folder search/search replace on files
> where
> the type is empty. I managed to solve this problem today by adding
> file extension mappings to my BBEdit Language preferences.
> Everything works the way I want. Just need to add any additional
> mappings a time goes on.
>
> A second issue I ran into recently is using a dotted folder name -
> using a namespace together with the word menu like 'mynamespace.menu'.
>
> Since I am developing in python, I create folders in subversion to
> keep namespace packages sorted out. This feature is common with
> repositories like svn.zope.org and other python repositories also.
> If I do a check out, it thinks the folder is a mac app file and not
> a folder. The .menu is what mac interprets as part of an app. This
> type of folder naming convention is not an issue on unix or windows
> (of course) and only appears on a check out. Not sure anything can
> be done about this one though. Many thanks.
True, on Mac OS X, directories whose names end in ".menu" are
considered to be MenuExtra bundles. The only suggestion I can make is
that if you intend to use these directories on Mac OS X, do not put
".menu" at the end of their names. I realize that the Zope developers
may be reluctant to change this. Unfortunately, if they do not remove
".menu" from the names of their directories, developing Zope on Mac
OS X will be exceptionally bizarre -- that is, if you intend to use
the Finder and standard save/open panels to navigate. If instead you
restrict yourself to the Terminal, bundles do not pose a problem.
Also, Finder replacements such as Path Finder offer the ability to
easily navigate into bundles, thus also alleviate the problem.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Advice on co with mac for file type/creator
Posted by David Pratt <fa...@eastlink.ca>.
Hi Ryan. Thank you for your reply. I do not generally worry about
creator types in mac either since file extensions are good enough for
opening applications. The trouble I had was more to do with BBEdit. It
did not want to do multi folder search/search replace on files where
the type is empty. I managed to solve this problem today by adding file
extension mappings to my BBEdit Language preferences. Everything works
the way I want. Just need to add any additional mappings a time goes on.
A second issue I ran into recently is using a dotted folder name - using
a namespace together with the word menu like 'mynamespace.menu'.
Since I am developing in python, I create folders in subversion to
keep namespace packages sorted out. This feature is common with
repositories like svn.zope.org and other python repositories also. If I
do a check out, it thinks the folder is a mac app file and not a folder.
The .menu is what mac interprets as part of an app. This type of folder
naming convention is not an issue on unix or windows (of course) and
only appears on a check out. Not sure anything can be done about this
one though. Many thanks.
Regards,
David
Ryan Schmidt wrote:
>
> On Dec 5, 2006, at 11:33, David Pratt wrote:
>
>> Hi. When I co from a svn repository on my mac, the file type and
>> creator are most often empty. I realize I can batch process folders to
>> set types based on extensions but I am wondering if someone has a
>> better solution for this - or can advise on how they cope with this.
>> Many thanks.
>
> Not really. Subversion does not store type / creator information, or
> resource forks. It stores the data fork only.
>
> On Mac OS X, I have not had to worry about type / creator information in
> many years; are you sure you have to? For example, if you have a bunch
> of, say, .txt files, and by default these open into, I don't know,
> TextEdit maybe, and you would rather use BBEdit, then just click one of
> the .txt files in the Finder, Get Info on it, in the Open With section
> select BBEdit, then click the Change All button, and from then on, all
> .txt files will open into BBEdit. No need to muck with type / creator
> codes ever again.
>
> Does that help you?
>
>
> --To reply to the mailing list, please use your mailer's Reply To All
> function
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Advice on co with mac for file type/creator
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 5, 2006, at 11:33, David Pratt wrote:
> Hi. When I co from a svn repository on my mac, the file type and
> creator are most often empty. I realize I can batch process folders
> to set types based on extensions but I am wondering if someone has
> a better solution for this - or can advise on how they cope with
> this. Many thanks.
Not really. Subversion does not store type / creator information, or
resource forks. It stores the data fork only.
On Mac OS X, I have not had to worry about type / creator information
in many years; are you sure you have to? For example, if you have a
bunch of, say, .txt files, and by default these open into, I don't
know, TextEdit maybe, and you would rather use BBEdit, then just
click one of the .txt files in the Finder, Get Info on it, in the
Open With section select BBEdit, then click the Change All button,
and from then on, all .txt files will open into BBEdit. No need to
muck with type / creator codes ever again.
Does that help you?
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org