You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tim Hill <ti...@realmsys.com> on 2006/03/01 20:14:58 UTC
Mac OS X "packages" Best Practices?
I have a question regarding best practices when using Subversion with
Mac OS X, particularly as related to the Mac's use of "packages".
=Background=
Mac OS X and some Mac Apps use "packages" in the file system to store
content. These are really just directories with known extensions that
Finder "pretends" are normal files. For example, Mac apps are supplied
as folder trees where the top-level folder has a ".app" extension. When
applications use packages to store documents, Subversion can get very
confused.
=Problem=
Consider the drawing application OmniGraffle, which stores drawings in
packages with an extension of ".graffle". Create a drawing and save it
as "foo.graffle". Remember, this isn't a normal file: it's a directory
that contains files, it just looks like a file in Finder.
Add this drawing to an SVN repository. This works fine, *however* at
this stage SVN creates its normal hidden ".svn" directory _inside_ the
package, since as far as it is concerned, this is a normal directory,
not a package.
Now update the drawing in OmniGraffle and save it. One of three things
will now happen depending upon the application:
(1) The application will update the _contents_ of the package, but not
touch the package directory itself. This is compatible with SVN and
causes no problems. However, I'm not aware of any Mac app that behaves
this way (nor should any, since its potentially unsafe).
(2) The application sees the ".svn" hidden directory in the package and
panics, since it cannot understand this. I think a good app should do
this, but again I'm not aware of any that do.
(3) The application creates a new temporary package, saves the updated
drawing to that location, then deletes the old package and renames the
new package to the final save name (foo.graffle). Most apps I'm aware of
use this approach.
Option (3) is the problem. A side-effect of saving the file in this way
is the elimination of the ".svn" folder created by SVN. This, of course,
confuses SVN no end when it comes to a later commit.
=Solutions=
I can see several possible work-arounds for this, and was looking for
feedback on what others (if any) do under these circumstances (other
than "use Linux instead", hehe).
(1) Edit and save in a temporary directory outside of the SVN working
copy, then hand patch the changes back into the package. This approach
seems to me rather fragile.
(2) Edit and save in a temporary directory, then wrap the package into a
real file, such as a ZIP, DMG or TAR, and check that into SVN. This
would work, but is rather labor intensive.
(3) Find some magic SVN command that would rebuild the .svn directory
without disturbing the updated content inside the package (which is now
different from the HEAD revision, remember).
#3 would seem best, but I have yet to find that magic command. Anyone
any ideas? Am I missing something obvious here?
Any input greatly appreciated.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Dave Camp <da...@thinbits.com>.
On Mar 1, 2006, at 12:14 PM, Tim Hill wrote:
> (2) The application sees the ".svn" hidden directory in the package
> and panics, since it cannot understand this. I think a good app
> should do this, but again I'm not aware of any that do.
>
> (3) The application creates a new temporary package, saves the
> updated drawing to that location, then deletes the old package and
> renames the new package to the final save name (foo.graffle). Most
> apps I'm aware of use this approach.
I'd suggest filing a bug with the software vendor(s) and ask them to
respect .svn folders. It's a common problem for Mac developers.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Markus <yo...@hispeed.ch>.
> I think, if I recall correctly, that a number of people already have
> script s that handle this.
>
> In any event, see
>
> <http://subversion.tigris.org/issues/show_bug.cgi?id=707>
> for a discussion of this problem.
>
> -Mike
I have read through the whole long thread in this newsgroup (the one
that started in March this year) and I have also read through the
comments in the link above but I could not find a reference to a script
which does this (I am sure somebody must have created one). If somebody
would be willing to share such a script, I think this could be useful
to a number of people.
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Mike Conley <no...@crystalmaker.com>.
On 24.09.2006, at 23.53 (UTC+0200), Markus scribbled thusly:
>Shouldn't it be fairly easy for an OS X subversion client to zip all
>bundles and tag the bundles itself to be ignored before it applied any
>'real' svn commands and in reverse whenever receiving any zip files,
>unzip them, check whether they are bundles (and if not delete the
>unzipped stuff).
I think a lot of people probably already do this. For a variety of reasons, all of which have been enumerated in the past, this is not an optimal solution.
>This approach assumes that people who care about bundles also run svn
>clients only on OS X since only OS X client would implement this
>approach.
That's an invalid assumption, on two counts: it assumes that only Mac OS X users are interested in opaque directories (or bundles), and it assumes that one would only ever be interested in checking Mac OS X code in or out onto a Mac platform. I, for example, do all of my Windows code editing on my Mac; I don't think it's a stretch to imagine that there might be people out there who occasionally (or regularly) need to edit Mac code from a Windows (or Linux, or whatever) box.
And opaque directories are useful for other platforms besides the Mac.
>Moreover, adding functionality to the subversion client for
>only one platform would go against the whole idea of platform
>independent code which would be probably not be very appreciated by the
>subversion developers.
One could argue that SVN has broken platform independence because one of the primary features of a not-insignificant platform which it supposedly supports is not properly (and transparently) supported.
>Therefore, I would propose to implement this idea only in OS X GUI
>clients, which already are in several cases OS X-only.
I think, if I recall correctly, that a number of people already have scripts that handle this.
In any event, see
<http://subversion.tigris.org/issues/show_bug.cgi?id=707>
for a discussion of this problem.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Markus <yo...@hispeed.ch>.
>> As far as svn stands, I think we're all at the position of "it would
>> be really nice if svn could treat some directories as opaque/atomic
>> but that isn't going to happen any time soon."
>
> In short, what it comes down to, is that this feature is fairly
> difficult to implement within the boundaries of the current working
> copy design. In order for it to get implemented, a well thought out
> design on how to implement it is going to be needed. The good news is
> that in the last couple of releases developers have been optimizing the
> working copy design and code, which means there are more developers who
> have been working in that area of the code and are feeling more
> comfortable with it. So if a design were to emerge, there are
> developers that should be able to comment on the proposal and help
> refine it.
> Mark
Shouldn't it be fairly easy for an OS X subversion client to zip all
bundles and tag the bundles itself to be ignored before it applied any
'real' svn commands and in reverse whenever receiving any zip files,
unzip them, check whether they are bundles (and if not delete the
unzipped stuff).
I have only a few days ago started working with svn, so I probably have
no real idea of what is easy or feasible but if the lack of a concept
to solve this problem is the main issue, maybe this might be a lead.
This approach assumes that people who care about bundles also run svn
clients only on OS X since only OS X client would implement this
approach. Moreover, adding functionality to the subversion client for
only one platform would go against the whole idea of platform
independent code which would be probably not be very appreciated by the
subversion developers.
Therefore, I would propose to implement this idea only in OS X GUI
clients, which already are in several cases OS X-only. It should be
seen as a feature of the OS X GUI client and not of subversion itself.
It is only an interim solution until the opaque/atomic tag would be in
subversion itself.
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Aaron Montgomery <ee...@monsterworks.com>.
On Mar 4, 2006, at 6:16 AM, Jim Correia wrote:
> Preserving the extra data on a safe-save or a save as requires
> extra work.
Oh, I agree, in fact, I think these two saves *should* remove any
extra information in the document.
> I tend to agree with Mike's point
Mike's original point seemed to be that it was absurd for a user to
make a RFE that the developer's product preserve subversion data. In
fact, Mike seemed to feel that by suggesting such a request, the
original poster was "(I'm trying to think of a nice way to put this)
-- right out" indicating that if Mike had spoken more freely, he
would have had some choice insults not suitable for prime time about
the mental facilities of the poster. I think that is what caused such
a visceral response on my part. I stand by the response that the
request is reasonable (although, like any RFE, it may not be
practical to implement and needs to be weighed against other
development considerations, e.g., the amount of effort required to
rewrite I/O routines and the likelihood of introducing errors in that
work). However, "please preserve extra data in your documents" is
certainly more reasonable than some of the requests that I've seen
(e.g., "please provide backward compatibility for my Mac SE/30
running System 7, oh, and can you provide the product on a floppy").
I guess part of the question is whose document is it? (Read at least
the next three sentences before responding.) The document does not
belong to the developer's application (or the developer), it belongs
to the user. If the user wants to write all sorts of crap into the
document, they should certainly be allowed to do that. It is
reasonable for the developer to respond to this by saying, "hey look,
you wrote all sorts of crap into the document, of course our product
won't read it any more". (Okay, that was the third sentence). This
doesn't make it unreasonable for the user to ask (politely) that the
application preserve the crap. The user certainly can't demand that
the product handle the crap, nor can the user claim the product is
broken/defective if it doesn't handle the crap. That's why I
suggested that this should be placed in the "Request for Enhancement"
category, not the "Bug" category. The user is just asking the
developer to add a new feature to the product that will extend its
usefulness (for this particular user) beyond the current design. That
sounds like a reasonable request to me, but again, that doesn't mean
that I would run out and implement it.
> this is a Subversion problem to solve.
I agree that Subversion should provide a solution.
Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Jim Correia <ji...@pobox.com>.
On Mar 3, 2006, at 9:44 AM, Aaron Montgomery wrote:
> Preserving extra stuff in the bundle would also better match how
> most applications worked in previous versions of the Mac OS (pre OS
> X). When I start with a SimpleText document, open it in THINK
> Pascal's editor, then in MPW's editor, then check it into VOODOO
> Source Code Control (each of which were probably considered well
> behaved Mac applications in their time), and then check it back
> out, the document picks up a whole slew of new resources (I can't
> remember them all, EFNT, MPSR, ckid). However, I am then able to
> open the file back up in SimpleText which ignores all of this extra
> material. In fact, I can't think of any application I've ever used
> in Classic that would have failed to open the TEXT document because
> it contained these extra resources. And I also don't remember
> continuing to use applications that would strip this data.
Ignoring the extra data was easy then, and is easy now. It mostly
just works. Preserving the extra data on a safe-save r a save as
requires extra work. Lots of applications in days of old didn't
preserve the 'CKID' resource, which broke Projector support.
I tend to agree with Mike's point - this is a Subversion problem to
solve.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 3/6/2006 11:09 AM, Daniel Berlin wrote:
> Err, there are people you can pay to consult and implement features for
> you in subversion.
For Geoffrey and others, it would be useful to give some pointers on how
best to find and contact these folks.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Daniel Berlin <db...@dberlin.org>.
On Sun, 2006-03-05 at 12:29 -0500, Geoffrey Alan Washburn wrote:
> Jeremy Pereira wrote:
>
> > On Mar 3, 2006, at 19:36, Geoffrey Alan Washburn wrote:
> >
> >> Ryan Schmidt wrote:
> >>> On Mar 3, 2006, at 16:34, Mike Conley wrote:
> >>>> I agree completely, and it's a shame. Anyone else who agrees should
> >>>> go an add votes to #707; I have no idea if they ever get paid any
> >>>> attention, but I don't imagine it can hurt.
> >>> The developers have previously stated that they do not pay attention
> >>> to votes.
> >>
> >> It seems kind of unfortunate that the developers maintain this attitude.
> >> What exactly do they pay attention to?
> >
> > As they are, for the most part, volunteers I think they pay attention to
> > the things they find interesting.
>
>
> So basically you're saying the developers don't find making their
> software usable interesting? That is interesting in of itself.
No, we just don't pay attention to random votes on random issues.
This is pretty typical of most projects. We aren't paid to do so, after
all.
If the issue really concerns you, either implement it, or pay someone to
do it for you!
>
>
> > If you don't like it, perhaps you could ask for your money back :-)
>
>
> Yawn. When are people going to learn that saying that makes you look
> silly. I'd, and probably a number of more serious users, would gladly
> pay someone to improve a number of problems in Subversion that the
> developers "don't seem to find interesting", but I don't see any
> developers lining up.
Err, there are people you can pay to consult and implement features for
you in subversion.
>
>
> >> Would they even accept a patch if someone went off and implemented this?
> >
> > Provided it meets the subversion quality standards.
> > Read the HACKING file in the source distribution.
>
>
> Clearly you haven't looked at this in a while, because it says to look
> at http://subversion.tigris.org/hacking.html. This document is very
> vague as to the process by which a patch is actually accepted. As far
> as it describes, submitting a patch is no more likely to make the
> developers accept it than voting will make them pay attention to an
> outstanding issue.
There is never a guarantee that any patch will be accepted, unless you
have the authority to commit it yourself. If you are looking for
someone to guarantee that if you implement something, it will be
accepted, you are out of luck.
However, in general, if it what the community wants, unless there is
something fundamentally flawed with it, it will be committed.
This is the way of the world. Red Hat, for example, has been
contracting this way for years (the contracts state they will make the
best efforts to get the patch into the main source code for the package
in question, but there are no guarantees).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 6, 2006, at 08:17, Jeremy Pereira wrote:
>>> No I am saying they have priorities that are not necessarily
>>> determined by what a small section of the community wants.
>>
>> Define small? I seem to recall people mentioning that this
>> affected plenty of people besides just Mac users.
>
> Define "plenty".
I think the "small section of the community" was meant to indicate
the small subset of Subversion users who know there's a bug tracker,
who know there's a record for this issue, who know issues can be
voted on and who have voted on it. Don't you also need to be logged
in as a Tigris user, and don't you then need to have Subversion in
your list of projects, which is a manual process on the part of the
Tigris admins? I think the point is there are many more Subversion
users than those who vote on issues, and I'm sure the Subversion
developers try to keep a handle on what they want, by whatever means
they can. Many people asked for locking; they got it in Subversion
1.3. Many people asked for merge tracking; maybe they'll get it in
1.4. Maybe we'll get opaque collections / document bundles in 1.9 or
who knows when.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Jeremy Pereira <je...@jeremyp.net>.
On Mar 6, 2006, at 06:17, Geoffrey Alan Washburn wrote:
>
> Jeremy Pereira wrote:
> > No I am saying they have priorities that are not necessarily
> > determined by what a small section of the community wants.
>
> Define small? I seem to recall people mentioning that this
> affected plenty of people besides just Mac users.
Define "plenty".
>
> > I happen to think that the feature request in question is one that
> > would be nice to have, being a Mac OS X developer myself (I also
> think
> > that the implementation of bundles by Mac OS X is fundamentally
> > broken).
>
> Bundles, originating in NeXTStep, have been implemented the way
> they have been for far longer than Subversion has been in
> existence. One could argue "executable" bits are fundamentally
> broken, and that extended attributes should be used, but Subversion
> support the former, but not the latter. Perhaps some people can
> wait for the perfect file-system and data storage paradigm to be
> invented, but some people need to work with what exists.
I said the implementation is fundamentally flawed, not the concept.
Execute bits might be a flawed concept but the implementation is not
flawed.
>
> >> Yawn. When are people going to learn that saying that makes
> you
> >> look silly. I'd, and probably a number of more serious users,
> would
> >> gladly pay someone to improve a number of problems in Subversion
> that
> >> the developers "don't seem to find interesting", but I don't see
> any
> >> developers lining up.
> >
> > Well the fact is, nobody has put any money up to fix this problem.
>
> What part about "I would pay to have have someone resolve this
> problem along with several other critical flaws" did you
> misinterpret? I'm sure that between all the interested parties
> enough money could be raised. But as I said, no one seems to be
> interested in stepping forward to do said work. I guess capitalism
> just isn't what it used to be.
You need to tell the developers that you are prepared to put the
money up, not the users. I suggest you post your offer on the dev
list. I expect you'll find this one comes out quite expensive since
it is not a trivial change and requires a good deal of thought to
implement it properly (that's probably the real reason it hasn't been
done yet).
I'd be happy to have a go for you at a price, but it'd be a risk for
you because I am not a subversion developer and I can't guarantee
that I could get the developers to accept my patch. Of course, in
that situation you could pay me even more money and I'd keep the
patch in line with whatever release of Subversion you are using.
You also don't know how good my coding skills are.
>
> > I disagree with your assertion that the document is vague about the
> > process for submitting patches. It seems perfectly explicit to me.
>
> It explains how to submit a patch, but not the criterion for
> one accepted into main source tree.
The subject has come up on this list before. If you do a search in
the archives, you'll probably find it.
>
> --
> [Geoff Washburn|geoffw@cis.upenn.edu|http://www.cis.upenn.edu/
> ~geoffw/]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Duncan Murdoch wrote:
> If you are serious about this, I'd suggest starting by contacting
> collab.net.
I will admit that I haven't contacted them directly, but last time I
checked their website, it didn't seem to indicate that they would be
interested in this sort of thing.
> They host the Subversion project; I believe some of the
> core developers work there (or used to).
Really, I had in mind something more like what Bram Moolenaar does with
vim or perhaps something based around http://www.fundable.org/.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 3/5/2006 4:17 PM, Geoffrey Alan Washburn wrote:
> >> Yawn. When are people going to learn that saying that makes you
> >> look silly. I'd, and probably a number of more serious users, would
> >> gladly pay someone to improve a number of problems in Subversion that
> >> the developers "don't seem to find interesting", but I don't see any
> >> developers lining up.
> >
> > Well the fact is, nobody has put any money up to fix this problem.
>
> What part about "I would pay to have have someone resolve this
> problem along with several other critical flaws" did you misinterpret?
> I'm sure that between all the interested parties enough money could be
> raised. But as I said, no one seems to be interested in stepping
> forward to do said work. I guess capitalism just isn't what it used to be.
If you are serious about this, I'd suggest starting by contacting
collab.net. They host the Subversion project; I believe some of the
core developers work there (or used to).
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Jeremy Pereira wrote:
> No I am saying they have priorities that are not necessarily
> determined by what a small section of the community wants.
Define small? I seem to recall people mentioning that this
affected plenty of people besides just Mac users.
> I happen to think that the feature request in question is one that
> would be nice to have, being a Mac OS X developer myself (I also think
> that the implementation of bundles by Mac OS X is fundamentally
> broken).
Bundles, originating in NeXTStep, have been implemented the way
they have been for far longer than Subversion has been in existence.
One could argue "executable" bits are fundamentally broken, and that
extended attributes should be used, but Subversion support the former,
but not the latter. Perhaps some people can wait for the perfect
file-system and data storage paradigm to be invented, but some people
need to work with what exists.
>> Yawn. When are people going to learn that saying that makes you
>> look silly. I'd, and probably a number of more serious users, would
>> gladly pay someone to improve a number of problems in Subversion that
>> the developers "don't seem to find interesting", but I don't see any
>> developers lining up.
>
> Well the fact is, nobody has put any money up to fix this problem.
What part about "I would pay to have have someone resolve this
problem along with several other critical flaws" did you misinterpret?
I'm sure that between all the interested parties enough money could be
raised. But as I said, no one seems to be interested in stepping
forward to do said work. I guess capitalism just isn't what it used to be.
> I disagree with your assertion that the document is vague about the
> process for submitting patches. It seems perfectly explicit to me.
It explains how to submit a patch, but not the criterion for one
accepted into main source tree.
--
[Geoff Washburn|geoffw@cis.upenn.edu|http://www.cis.upenn.edu/~geoffw/]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Jeremy Pereira <je...@jeremyp.net>.
On Mar 6, 2006, at 02:29, Geoffrey Alan Washburn wrote:
> Jeremy Pereira wrote:
>
>> As they are, for the most part, volunteers I think they pay
>> attention to the things they find interesting.
>
>
> So basically you're saying the developers don't find making their
> software usable interesting? That is interesting in of itself.
No I am saying they have priorities that are not necessarily
determined by what a small section of the community wants.
I happen to think that the feature request in question is one that
would be nice to have, being a Mac OS X developer myself (I also
think that the implementation of bundles by Mac OS X is fundamentally
broken). However, I am not prepared to criticise the developers for
ignoring it because I haven't paid them anything to use subversion.
I have the fruits of their labour for free. I could implement the
feature myself, but I have more interesting things to do. It seems
hypocritical to allow myself that excuse, but not the developers.
>
>
>> If you don't like it, perhaps you could ask for your money back :-)
>
>
> Yawn. When are people going to learn that saying that makes you
> look silly. I'd, and probably a number of more serious users,
> would gladly pay someone to improve a number of problems in
> Subversion that the developers "don't seem to find interesting",
> but I don't see any developers lining up.
Well the fact is, nobody has put any money up to fix this problem.
>
>
>>> Would they even accept a patch if someone went off and
>>> implemented this?
>> Provided it meets the subversion quality standards.
> > Read the HACKING file in the source distribution.
>
>
> Clearly you haven't looked at this in a while, because it says to
> look at http://subversion.tigris.org/hacking.html. This document
> is very vague as to the process by which a patch is actually
> accepted. As far as it describes, submitting a patch is no more
> likely to make the developers accept it than voting will make them
> pay attention to an outstanding issue.
>
Mea culpa. I looked at the distro I have on this laptop which is
only 1.2.3. However, if the hacking file is now just a link, you can
still get the information you need by looking at the file and then
following its instruction to use the link.
I disagree with your assertion that the document is vague about the
process for submitting patches. It seems perfectly explicit to me.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Mark Phippard <ma...@softlanding.com>.
news <ne...@sea.gmane.org> wrote on 03/05/2006 12:29:51 PM:
> > As they are, for the most part, volunteers I think they pay attention
to
> > the things they find interesting.
>
> So basically you're saying the developers don't find making their
> software usable interesting? That is interesting in of itself.
The Subversion developers do not rely on the votes just because they do
not think the feature really means anything. The Subversion community is
wide and only a small fraction know about the issue tracker. The vote
counts just are not significant in and of themselves. That does not mean
that any given developer might not take a look at the votes to get a sense
as to what people are concerned with. It just means that no one is
willing to make any guarantees that having a high vote count is going to
equal implementation.
I doubt that you would find a single Subversion developer that is against
the basic idea of this feature. The issues are that an acceptable design
for the feature has not surfaced, and developer time is scarce. In the
past there have been issues like locking that seemed more pressing, and
currently the time is being spent on features like merge tracking. That
being said, anyone can be a Subversion developer by simply being motivated
to work on a design for the feature.
> >> Would they even accept a patch if someone went off and implemented
this?
> >
> > Provided it meets the subversion quality standards.
> > Read the HACKING file in the source distribution.
>
>
> Clearly you haven't looked at this in a while, because it says to
look
> at http://subversion.tigris.org/hacking.html. This document is very
> vague as to the process by which a patch is actually accepted. As far
> as it describes, submitting a patch is no more likely to make the
> developers accept it than voting will make them pay attention to an
> outstanding issue.
The HACKING file is about the code standards. You are right, that is only
a small part of what it takes to get a patch committed. The main thing is
that an acceptable design is needed. With a good design that is generally
agreed upon, one of the existing developers might even take up the job of
coding it. What will almost never be accepted is a patch that is dropped
in out of the blue with no written design to validate it against, and no
discussion of the design.
In short, what it comes down to, is that this feature is fairly difficult
to implement within the boundaries of the current working copy design. In
order for it to get implemented, a well thought out design on how to
implement it is going to be needed. The good news is that in the last
couple of releases developers have been optimizing the working copy design
and code, which means there are more developers who have been working in
that area of the code and are feeling more comfortable with it. So if a
design were to emerge, there are developers that should be able to comment
on the proposal and help refine it.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Re: Mac OS X "packages" Best Practices?
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Jeremy Pereira wrote:
> On Mar 3, 2006, at 19:36, Geoffrey Alan Washburn wrote:
>
>> Ryan Schmidt wrote:
>>> On Mar 3, 2006, at 16:34, Mike Conley wrote:
>>>> I agree completely, and it's a shame. Anyone else who agrees should
>>>> go an add votes to #707; I have no idea if they ever get paid any
>>>> attention, but I don't imagine it can hurt.
>>> The developers have previously stated that they do not pay attention
>>> to votes.
>>
>> It seems kind of unfortunate that the developers maintain this attitude.
>> What exactly do they pay attention to?
>
> As they are, for the most part, volunteers I think they pay attention to
> the things they find interesting.
So basically you're saying the developers don't find making their
software usable interesting? That is interesting in of itself.
> If you don't like it, perhaps you could ask for your money back :-)
Yawn. When are people going to learn that saying that makes you look
silly. I'd, and probably a number of more serious users, would gladly
pay someone to improve a number of problems in Subversion that the
developers "don't seem to find interesting", but I don't see any
developers lining up.
>> Would they even accept a patch if someone went off and implemented this?
>
> Provided it meets the subversion quality standards.
> Read the HACKING file in the source distribution.
Clearly you haven't looked at this in a while, because it says to look
at http://subversion.tigris.org/hacking.html. This document is very
vague as to the process by which a patch is actually accepted. As far
as it describes, submitting a patch is no more likely to make the
developers accept it than voting will make them pay attention to an
outstanding issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Jeremy Pereira <je...@jeremyp.net>.
On Mar 3, 2006, at 19:36, Geoffrey Alan Washburn wrote:
> Ryan Schmidt wrote:
>> On Mar 3, 2006, at 16:34, Mike Conley wrote:
>>> I agree completely, and it's a shame. Anyone else who agrees
>>> should go an add votes to #707; I have no idea if they ever get
>>> paid any attention, but I don't imagine it can hurt.
>> The developers have previously stated that they do not pay
>> attention to votes.
>
> It seems kind of unfortunate that the developers maintain this
> attitude.
> What exactly do they pay attention to?
As they are, for the most part, volunteers I think they pay attention
to the things they find interesting. If you don't like it, perhaps
you could ask for your money back :-)
> Would they even accept a patch if someone went off and implemented
> this?
Provided it meets the subversion quality standards. Read the HACKING
file in the source distribution.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
>
> On Mar 3, 2006, at 16:34, Mike Conley wrote:
>
>> I agree completely, and it's a shame. Anyone else who agrees should go
>> an add votes to #707; I have no idea if they ever get paid any
>> attention, but I don't imagine it can hurt.
>
> The developers have previously stated that they do not pay attention to
> votes.
It seems kind of unfortunate that the developers maintain this attitude.
What exactly do they pay attention to? Would they even accept a patch
if someone went off and implemented this?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 3, 2006, at 16:34, Mike Conley wrote:
> I agree completely, and it's a shame. Anyone else who agrees should
> go an add votes to #707; I have no idea if they ever get paid any
> attention, but I don't imagine it can hurt.
The developers have previously stated that they do not pay attention
to votes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Mike Conley <no...@crystalmaker.com>.
On 03.03.2006, at 06.44 (UTC-0800), Aaron Montgomery scribbled thusly:
>As far as svn stands, I think we're all at the position of "it would
>be really nice if svn could treat some directories as opaque/atomic
>but that isn't going to happen any time soon."
I agree completely, and it's a shame. Anyone else who agrees should go an add votes to #707; I have no idea if they ever get paid any attention, but I don't imagine it can hurt.
I hesitate to add comments to the report, as pretty much everything that needs to be said there has been said.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Aaron Montgomery <ee...@monsterworks.com>.
On Mar 3, 2006, at 1:27 AM, Mike Conley wrote:
> On 02.03.2006, at 20.08 (UTC-0800), Dave Camp scribbled thusly:
>
>> I contend that applications that do not respect extra contents added
>> to a bundle are equally at fault. When Pages (as an example) saves
>> the open document, it blows away any additional files that were in
>> the in the document bundle instead of preserving them.
>
> You're placing the burden of support on the wrong shoulders. I
> don't see that other applications/processes have any business
> adding data to another application's bundle; if they do, it's not
> the target application's fault for failing to notice or respect
> said data.
Preserving extra stuff in the bundle would also better match how most
applications worked in previous versions of the Mac OS (pre OS X).
When I start with a SimpleText document, open it in THINK Pascal's
editor, then in MPW's editor, then check it into VOODOO Source Code
Control (each of which were probably considered well behaved Mac
applications in their time), and then check it back out, the document
picks up a whole slew of new resources (I can't remember them all,
EFNT, MPSR, ckid). However, I am then able to open the file back up
in SimpleText which ignores all of this extra material. In fact, I
can't think of any application I've ever used in Classic that would
have failed to open the TEXT document because it contained these
extra resources. And I also don't remember continuing to use
applications that would strip this data. In fact, one nice feature of
each application's ignorance to the extra data was that all of these
different applications could open and change the contents of the file
(including adding information only useful to themselves) without
causing the file to be incompatible with the other applications.
In any case, I don't think we're on-topic any more. We're now having
a debate about what a Mac OS X package is or is not and about what
other Mac programs are or are not allowed to do to another program's
document. As far as svn stands, I think we're all at the position of
"it would be really nice if svn could treat some directories as
opaque/atomic but that isn't going to happen any time soon."
Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Mike Conley <no...@crystalmaker.com>.
On 03.03.2006, at 09.27 (UTC-0000), Mike Conley scribbled thusly:
>The solution is to modify SVN so that the owner of a repository can tag a
>particular directory as being opaque
'Opaque' is perhaps not the best word here; 'atomic' might be better. The point being, the directory should be treated by SVN such that a change to *any* file contained in it is considered a modification to the directory as a whole, and the repository is accordingly updated.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Mike Conley <no...@crystalmaker.com>.
On 02.03.2006, at 20.08 (UTC-0800), Dave Camp scribbled thusly:
>I contend that applications that do not respect extra contents added
>to a bundle are equally at fault. When Pages (as an example) saves
>the open document, it blows away any additional files that were in
>the in the document bundle instead of preserving them.
You're placing the burden of support on the wrong shoulders. I don't see that other applications/processes have any business adding data to another application's bundle; if they do, it's not the target application's fault for failing to notice or respect said data.
If Subversion went about tacking extra crap onto the end of every file under its control as a means of tracking changes, applications would be no more responsible for blowing those data away than they are for losing the .svn directory when they make changes to bundles. Bundles are, except to the application that created them and to the OS, an atomic structure under Mac OS X, and are not to be toyed with by other components. There are APIs for examining and extracting information about bundles; they are not to be treated as directories, as it's entirely possible (though, admittedly, unlikely) that this structure could change in the future.
The solution is to modify SVN so that the owner of a repository can tag a particular directory as being opaque; SVN would then be required to treat the target directory as it would a file and maintain state information in its enclosing directory. This solves the problem without making it Mac-specific; this would be generic, would work on any OS, and would be useful to other than Mac users as well.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Dave Camp <da...@thinbits.com>.
>> No. It's a real problem for anyone trying to place document bundles
>> under source control.
>
> I'm sorry, guys, but that's (I'm trying to think of a nice way to
> put this) -- right out.
>
> Application developers are not responsible for maintaining
> compatiblity with source code control systems whose mechanism for
> tracking changes may vary wildly across different systems and even
> from one version of the SCCS to another. Application developers are
> responsible for ensuring that their products conform to the
> requirements of the OS upon which they run.
>
> It is the responsibility of the SCCS developer to ensure that the
> SCCS works with the OSes upon which his system is expected to run.
> In this case, that means that Subversion should be updated to
> support the package model used on Mac OS X, which change could be
> made sufficiently generic as to be potentially useful to developers
> on other platforms as well.
>
> This requires a single point of change, SVN, rather than having
> every Mac OS X developer on the planet rewrite his file I/O code to
> deal with the idiosyncracies of a single SCCS -- an interesting
> viewpoint, to be sure.
I contend that applications that do not respect extra contents added
to a bundle are equally at fault. When Pages (as an example) saves
the open document, it blows away any additional files that were in
the in the document bundle instead of preserving them. It's not an
issue specific to source control. It would apply equally well to any
other process that might add a file to a document bundle.
It certainly would be nice if svn had a built in way of bypassing
this issue, but I don't have much hope for that.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Tim Hill <ti...@realmsys.com>.
Well, we have two discussion points here, I think...
(1) The design of the bundle/package system in Mac OS X.
(2) If and how Subversion should handle this issue.
<editorial>
(1) There is no doubt of a need for structured storage *within* the
user-paradigm of a "file". There are really two options: (a)
standardized file formats or (b) folders-as-files. Both extend the
directory tree "into" the file, but each from an opposite perspective.
Microsoft chose the (a) approach with structured storage (i.e. OLE
documents), and so did OpenDoc, which are really ZIP files (as, for that
matter, are Java JAR files). Apple chose (b). There are pros and cons to
both models. (a) offers a more consistent "view", since only apps that
known how to crack open the file do so. The flip side is that a lack of
standards makes tool development harder: consider search issues. (b)
enforces a consistent model and leverages the file system code to also
provide the "interior" view (a significant advantage, imho). But it's
too easy for tools to "miss" the folder decoration and damage the package.
Regardless of merits, I think Apple made a big mistake with the design
of their folders-as-files solution, since they distinguish regular
folders from "bundles" by the extension to the folder. For example,
"foo.app" is an application bundle by virtue of its ".app" extension
_and nothing else_. This is a mistake, since it means one has to know
the list of extensions that mark folders as bundles. (There is also a
"bundle" bit, but this is not the _only_ mechanism). It means, for
example, that any Subversion solution to this problem has to handle a
lot of Mac behavior in order to make sense of this. If the only
mechanism was the "bundle" bit in the folder,
</editorial>
(2) How can Subversion handle this?
(a) Ignore it. The issue was opened in 2002, with no comment for 24
months. I would assert therefore that this is indeed what is happening.
Presumably this is considered low priority, though I'm surprised by this.
(b) Publish a work-around. I have decided for the time being to wrap all
packages into ZIP files before checkin. This is painful, but do-able and
does sort of work. Of course, DIFFs are out, but its better than
nothing. Putting some discussion of this in the SVN book might be a good
idea.
(c) Design a fix. I'm happy to look into the design of such a feature
and start the necessary discussions, though I simply don't have the
bandwidth to develop a patch right now.
Thoughts, anyone?
--Tim
Aaron Montgomery wrote:
>
> On Mar 2, 2006, at 10:09 AM, Mike Conley wrote:
>
>> On 02.03.2006, at 09.56 (UTC-0800), Aaron Montgomery scribbled thusly:
>>
>>> Correct, but in the Mac OS X file system, a bundle is a directory.
>>> If the developer wants the document to be treated as a single opaque
>>> object in the file system, he/she needs to create a file, not a
>>> directory. If the developer creates a directory, he/she should allow
>>> that directory to be treated like a directory.
>>
>> Sorry, no, that's not the way Mac OS X works. Bundles are integral to
>> the way applications are packaged and store data now, and they are
>> intended to be opaque to the user. The Finder maintains this illusion
>> (although it also allows a means by which the user can see inside the
>> bundle if he really wants to).
>
> You cannot get around that they are directories, whether or not the
> Finder presents them as files. In fact, the first line of Apple's "The
> Bundle Programming Guide" is pretty explicit about them being
> directories: "A bundle is a directory in the file system that groups
> related resources together in one place." Admittedly, if it is a
> package, it is supposed to be presented as an opaque object to users.
> Unfortunately, it is clear from how they are treated in the Terminal
> and through File Systems calls, that "users" refers to people working
> through the Finder.
>
> I didn't say that it wouldn't be nice if SVN allowed directories and
> their contents to be treated as opaque binary objects (although this
> could get tricky to program, which might be why they haven't done it).
> All I said was that allowing svn subfolders was a reasonable feature
> request that the developer may or may not be able to accommodate. The
> developer may not even be aware that there is a problem with their
> bundle structure, it may be an easy fix, and the change would allow
> the developer's documents to play nice with CVS, SVN and any other
> UNIX program that treats directories like directories. If the
> developer is aware of the problem but it is a difficult to fix, then
> they might not fix it, but that doesn't make the request unreasonable,
> just one that cannot be accommodated. If your current problem really
> is just OmniGraffle, I've always found the Omni Group to be reasonably
> accommodating. Even if they cannot fix it, the worst they will do is
> nicely tell you that it just cannot be done.
>
> Asking the developer also seems like the most practical avenue at this
> point, since it is unlikely SVN programmers are going to rush out and
> fix this (it has been years since it was reported); and also unlikely
> that Apple is going to fix this (they adjusted their own code to
> handle svn folders in nib files).
>
> It was just a suggestion that might have helped you solve your
> immediate problem, take it or leave it.
>
> Aaron
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Aaron Montgomery <ee...@monsterworks.com>.
On Mar 2, 2006, at 10:09 AM, Mike Conley wrote:
> On 02.03.2006, at 09.56 (UTC-0800), Aaron Montgomery scribbled thusly:
>
>> Correct, but in the Mac OS X file system, a bundle is a directory.
>> If the developer wants the document to be treated as a single opaque
>> object in the file system, he/she needs to create a file, not a
>> directory. If the developer creates a directory, he/she should allow
>> that directory to be treated like a directory.
>
> Sorry, no, that's not the way Mac OS X works. Bundles are integral
> to the way applications are packaged and store data now, and they
> are intended to be opaque to the user. The Finder maintains this
> illusion (although it also allows a means by which the user can see
> inside the bundle if he really wants to).
You cannot get around that they are directories, whether or not the
Finder presents them as files. In fact, the first line of Apple's
"The Bundle Programming Guide" is pretty explicit about them being
directories: "A bundle is a directory in the file system that groups
related resources together in one place." Admittedly, if it is a
package, it is supposed to be presented as an opaque object to users.
Unfortunately, it is clear from how they are treated in the Terminal
and through File Systems calls, that "users" refers to people working
through the Finder.
I didn't say that it wouldn't be nice if SVN allowed directories and
their contents to be treated as opaque binary objects (although this
could get tricky to program, which might be why they haven't done
it). All I said was that allowing svn subfolders was a reasonable
feature request that the developer may or may not be able to
accommodate. The developer may not even be aware that there is a
problem with their bundle structure, it may be an easy fix, and the
change would allow the developer's documents to play nice with CVS,
SVN and any other UNIX program that treats directories like
directories. If the developer is aware of the problem but it is a
difficult to fix, then they might not fix it, but that doesn't make
the request unreasonable, just one that cannot be accommodated. If
your current problem really is just OmniGraffle, I've always found
the Omni Group to be reasonably accommodating. Even if they cannot
fix it, the worst they will do is nicely tell you that it just cannot
be done.
Asking the developer also seems like the most practical avenue at
this point, since it is unlikely SVN programmers are going to rush
out and fix this (it has been years since it was reported); and also
unlikely that Apple is going to fix this (they adjusted their own
code to handle svn folders in nib files).
It was just a suggestion that might have helped you solve your
immediate problem, take it or leave it.
Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Mike Conley <no...@crystalmaker.com>.
On 02.03.2006, at 09.56 (UTC-0800), Aaron Montgomery scribbled thusly:
>Correct, but in the Mac OS X file system, a bundle is a directory.
>If the developer wants the document to be treated as a single opaque
>object in the file system, he/she needs to create a file, not a
>directory. If the developer creates a directory, he/she should allow
>that directory to be treated like a directory.
Sorry, no, that's not the way Mac OS X works. Bundles are integral to the way applications are packaged and store data now, and they are intended to be opaque to the user. The Finder maintains this illusion (although it also allows a means by which the user can see inside the bundle if he really wants to).
No current filesystem used by Mac OS X supports bundles as such; they are always directories (or folders). It's not up to the developer whether a bundle is treated as a directory or as a file; if a bundle is needed, it's needed.
Again, it's up to the SCCS to deal with this, as it is a requirement for use on Mac OS X systems. And, as the commentary in case #707 points out, Mac OS X is not the only environment in which one might wish to have this capability. The fact that neither SVN nor, as I recall, CVS (except after some hacking by Apple) do this is extremely unfortunate, and is the primary reason I haven't put my Mac code under SVN yet, although XCode 1.2+ seems to have been modified to deal with SVN's hidden directory.
(This latter is a case in which it could be considered reasonable for the application to handle this, as XCode has integrated support for SVN and is a development tool.)
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Aaron Montgomery <ee...@monsterworks.com>.
On Mar 2, 2006, at 9:04 AM, Mike Conley wrote:
> On 02.03.2006, at 08.10 (UTC-0800), Aaron Montgomery scribbled thusly:
>
>> I'm not the original poster, but I doubt he was kidding. ... I think
>> many Mac developers (myself included) would consider this a
>> reasonable
>> request.
>
> On 02.03.2006, at 07.57 (UTC-0800), Dave Camp scribbled thusly:
>
>> No. It's a real problem for anyone trying to place document bundles
>> under source control.
>
> I'm sorry, guys, but that's (I'm trying to think of a nice way to
> put this) -- right out.
>
> Application developers are not responsible for maintaining
> compatibility with source code control systems whose mechanism for
> tracking changes may vary wildly across different systems and even
> from one version of the SCCS to another. Application developers are
> responsible for ensuring that their products conform to the
> requirements of the OS upon which they run.
Correct, but in the Mac OS X file system, a bundle is a directory.
If the developer wants the document to be treated as a single opaque
object in the file system, he/she needs to create a file, not a
directory. If the developer creates a directory, he/she should allow
that directory to be treated like a directory.
Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Mike Conley <no...@crystalmaker.com>.
On 02.03.2006, at 08.10 (UTC-0800), Aaron Montgomery scribbled thusly:
>I'm not the original poster, but I doubt he was kidding. ... I think
>many Mac developers (myself included) would consider this a reasonable
>request.
On 02.03.2006, at 07.57 (UTC-0800), Dave Camp scribbled thusly:
>No. It's a real problem for anyone trying to place document bundles
>under source control.
I'm sorry, guys, but that's (I'm trying to think of a nice way to put this) -- right out.
Application developers are not responsible for maintaining compatiblity with source code control systems whose mechanism for tracking changes may vary wildly across different systems and even from one version of the SCCS to another. Application developers are responsible for ensuring that their products conform to the requirements of the OS upon which they run.
It is the responsibility of the SCCS developer to ensure that the SCCS works with the OSes upon which his system is expected to run. In this case, that means that Subversion should be updated to support the package model used on Mac OS X, which change could be made sufficiently generic as to be potentially useful to developers on other platforms as well.
This requires a single point of change, SVN, rather than having every Mac OS X developer on the planet rewrite his file I/O code to deal with the idiosyncracies of a single SCCS -- an interesting viewpoint, to be sure.
>If the software doesn't work right for you, you should complain.
>Sometimes things get fixed if you complain...
Yes, well, the complaint is directed at the SVN development team, then, in the form of case #707, as noted earlier.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Aaron Montgomery <ee...@monsterworks.com>.
On Mar 2, 2006, at 6:49 AM, Mike Conley wrote:
> On 01.03.2006, at 19.34 (UTC-0800), Dave Camp scribbled thusly:
>
>> I'd suggest filing a bug with the software vendor(s) and ask them to
>> respect .svn folders. It's a common problem for Mac developers.
>
> You're kidding, right?
I'm not the original poster, but I doubt he was kidding. I would
suggest filing it as a "Request for Enhancement" instead of a "Bug",
but I think many Mac developers (myself included) would consider this
a reasonable request.
Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Dave Camp <da...@thinbits.com>.
On Mar 2, 2006, at 6:49 AM, Mike Conley wrote:
> On 01.03.2006, at 19.34 (UTC-0800), Dave Camp scribbled thusly:
>
>> I'd suggest filing a bug with the software vendor(s) and ask them to
>> respect .svn folders. It's a common problem for Mac developers.
>
> You're kidding, right?
No. It's a real problem for anyone trying to place document bundles
under source control. If the software doesn't work right for you, you
should complain. Sometimes things get fixed if you complain...
<rant>
What baffles me is how the developers of said Mac applications don't
discover the problem when they use their own software. For example,
you would think the engineers working on Pages would have discovered
they cannot check their own documents into CVS or SVN. I know Apple
uses CVS and SVN for source control, and I would hope the developers
use their own software for internal documentation. How could the
engineers produce software that doesn't even work for themselves?
</rant>
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Mike Conley <no...@crystalmaker.com>.
On 01.03.2006, at 21.34 (UTC+0100), Ryan Schmidt scribbled thusly:
>> I have a question regarding best practices when using Subversion
>> with Mac OS X, particularly as related to the Mac's use of "packages".
>
>It has come up on the list several times before. The solution to the
>problem will be the implementation of this feature request:
>
>http://subversion.tigris.org/issues/show_bug.cgi?id=707
Note that the open date on this bug report is 20 May 2002, the last comment was made on 22 Dec 2004, and it's still unscheduled. This would tend to imply a lack of any sense of urgency regarding its implementation, despite the fact that this would seem to be quite a useful feature.
On 01.03.2006, at 19.34 (UTC-0800), Dave Camp scribbled thusly:
>I'd suggest filing a bug with the software vendor(s) and ask them to
>respect .svn folders. It's a common problem for Mac developers.
You're kidding, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 1, 2006, at 21:14, Tim Hill wrote:
> I have a question regarding best practices when using Subversion
> with Mac OS X, particularly as related to the Mac's use of "packages".
It has come up on the list several times before. The solution to the
problem will be the implementation of this feature request:
http://subversion.tigris.org/issues/show_bug.cgi?id=707
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Why .svn directory? (was: Mac OS X "packages" Best
Practices?)
Posted by Fabian Cenedese <Ce...@indel.ch>.
At 07:55 03.03.2006 -0500, Duncan Murdoch wrote:
>On 3/2/2006 5:45 PM, Richard Jolly wrote:
>>On 2 Mar 2006, at 18:51, Russ Brown wrote:
>>
>>>I've come to this thread a little late but I do have an alternative
>>>solution: use SVK as your client instead of svn. SVK uses a different
>>>working copy format that doesn't involve adding .svn directories to each
>>>and every directory in the working copy. In fact it doesn't add anything
>>>to the working copy: the working copy information is stored elsewhere.
>>... in ~/.svk
>>Which has the nice effect that all the other unix tools don't constantly bump into the .svn dirs. I'm curious why doesn't subversion itself take this approach?
>
>I'm also curious, and have changed the subject line to hopefully attract more answers.
>
>I think there are some overly simple answers:
>
>1. Because CVS did it that way, and SVN is a descendant.
>
>2. Because SVN stores a duplicate of each working copy, and it's nice to get rid of both the WC and it's duplicate with a simple rm -rf.
>
>3. Because the user who checked out the working copy may not be the only one to access it; it would be hard to synchronize multiple ~/.svn files without some sort of info stored in the working copy to point to them.
>
>But I suspect there are better answers...
>
>I also really like the idea of keeping a duplicate of the repository on disk as a reference the way SVK does, instead of just a duplicate of the working copy as SVN does. I often have two or three branches of my project checked out, so I suspect the total disk space would be comparable, but I'd have the advantage of being able to look through the history even when offline.
I have a use case where it would be pretty usefull if the .svn were not besides
the handled files. We have a tool that saves data in different files in different
folders, it's a whole tree of data, new folders get added, others deleted. But
momentarily there's no possibility to sync these changes with a repository,
especially the deleted items. svn del file just won't work if the file is not
present anymore. And that's provided you still know what files got deleted.
I would like the svn data in a separate folder with the same tree structure
as the handled data, preferably right next to this data. So if a folder gets
deleted the svn data is still available and can be used to e.g. delete this
data also from the repository.
e.g.
BaseFolder/
File1
File2
DataFolder/
File3
File4
SubData/
File5
.svn
.svn
(existing info about File1, File2 and DataFolder)
DataFolder/
.svn
SubData/
.svn
Then I could do:
echo "new data" >> BaseFolder/File1
rm -f BaseFolder/DataFolder/SubData
mkdir BaseFolder/Data2
echo "works" > BaseFolder/Data2/NewFile
svn sync BaseFolder -m "Newest Changes"
D DataFolder/SubData/File5
D DataFolder/SubData
A BaseFolder/Data2
A BaseFolder/Data2/NewFile
M BaseFolder/File1
Would that be something for others as well? The .svn and corresponding
files would still be in one place and can be copied around or just rm'd all
at once.
bye Fabi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Why .svn directory? (was: Mac OS X "packages" Best Practices?)
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 3/2/2006 5:45 PM, Richard Jolly wrote:
> On 2 Mar 2006, at 18:51, Russ Brown wrote:
>
>> I've come to this thread a little late but I do have an alternative
>> solution: use SVK as your client instead of svn. SVK uses a different
>> working copy format that doesn't involve adding .svn directories to
>> each
>> and every directory in the working copy. In fact it doesn't add
>> anything
>> to the working copy: the working copy information is stored elsewhere.
>
> ... in ~/.svk
>
> Which has the nice effect that all the other unix tools don't
> constantly bump into the .svn dirs. I'm curious why doesn't subversion
> itself take this approach?
I'm also curious, and have changed the subject line to hopefully attract
more answers.
I think there are some overly simple answers:
1. Because CVS did it that way, and SVN is a descendant.
2. Because SVN stores a duplicate of each working copy, and it's nice
to get rid of both the WC and it's duplicate with a simple rm -rf.
3. Because the user who checked out the working copy may not be the
only one to access it; it would be hard to synchronize multiple ~/.svn
files without some sort of info stored in the working copy to point to them.
But I suspect there are better answers...
I also really like the idea of keeping a duplicate of the repository on
disk as a reference the way SVK does, instead of just a duplicate of the
working copy as SVN does. I often have two or three branches of my
project checked out, so I suspect the total disk space would be
comparable, but I'd have the advantage of being able to look through the
history even when offline.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Richard Jolly <ri...@mac.com>.
On 2 Mar 2006, at 18:51, Russ Brown wrote:
> I've come to this thread a little late but I do have an alternative
> solution: use SVK as your client instead of svn. SVK uses a different
> working copy format that doesn't involve adding .svn directories to
> each
> and every directory in the working copy. In fact it doesn't add
> anything
> to the working copy: the working copy information is stored elsewhere.
... in ~/.svk
Which has the nice effect that all the other unix tools don't
constantly bump into the .svn dirs. I'm curious why doesn't subversion
itself take this approach?
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Mac OS X "packages" Best Practices?
Posted by Russ Brown <pi...@gmail.com>.
On Wed, 2006-03-01 at 12:14 -0800, Tim Hill wrote:
> =Problem=
> Consider the drawing application OmniGraffle, which stores drawings in
> packages with an extension of ".graffle". Create a drawing and save it
> as "foo.graffle". Remember, this isn't a normal file: it's a directory
> that contains files, it just looks like a file in Finder.
>
> Add this drawing to an SVN repository. This works fine, *however* at
> this stage SVN creates its normal hidden ".svn" directory _inside_ the
> package, since as far as it is concerned, this is a normal directory,
> not a package.
>
> Now update the drawing in OmniGraffle and save it. One of three things
> will now happen depending upon the application:
>
> (3) The application creates a new temporary package, saves the updated
> drawing to that location, then deletes the old package and renames the
> new package to the final save name (foo.graffle). Most apps I'm aware of
> use this approach.
>
> Option (3) is the problem. A side-effect of saving the file in this way
> is the elimination of the ".svn" folder created by SVN. This, of course,
> confuses SVN no end when it comes to a later commit.
I've come to this thread a little late but I do have an alternative
solution: use SVK as your client instead of svn. SVK uses a different
working copy format that doesn't involve adding .svn directories to each
and every directory in the working copy. In fact it doesn't add anything
to the working copy: the working copy information is stored elsewhere.
Of course, this doesn't solve the general problem of using svn with Mac OS
X, but it is a potential solution to your specific problem.
--
Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org