You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrew Brosnan <an...@broscom.com> on 2006/07/20 18:19:41 UTC
Automating svn add, delete
Hello,
I'm setting up a project that will have some fairly non-technical folks
accessing some files under version control. (For example designers and
HTML files.) Changes will be made on one working copy only, and I plan
to automate/script commits and updates for them. However, I wonder about
the best way to handle adds and deletes. I've considered parsing the
output of status and then issuing any needed commands. However I assume
there is a better way. Any suggestions?
Regards,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automating svn add, delete
Posted by Eric Hanchrow <of...@blarg.net>.
Oops -- I mistyped the URL. It should be
http://subversion.tigris.org/faq.html#wc-change-detection
--
I shrivel inside each time [Star Wars] is mentioned.
-- Sir Alec Guinness
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automating svn add, delete
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Eric Hanchrow wrote:
>>>>>> "Andrew" == Andrew Brosnan <an...@broscom.com> writes:
>
> Andrew> Hello, I'm setting up a project that will have some fairly
> Andrew> non-technical folks accessing some files under version
> Andrew> control. (For example designers and HTML files.) Changes
> Andrew> will be made on one working copy only
>
> I would gently urge you to reconsider that -- that scheme loses many
> of the benefits of version control.
I've seen the results of doing things this way: they're not pretty with any
source control system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automating svn add, delete
Posted by Andrew Brosnan <an...@broscom.com>.
On 7/20/06 at 11:39 AM, offby1@blarg.net (Eric Hanchrow) wrote:
> >>>>> "Andrew" == Andrew Brosnan <an...@broscom.com> writes:
>
> Andrew> Hello, I'm setting up a project that will have some fairly
> Andrew> non-technical folks accessing some files under version
> Andrew> control. (For example designers and HTML files.) Changes
> Andrew> will be made on one working copy only
>
> > I would gently urge you to reconsider that -- that scheme loses many
> > of the benefits of version control.
I miss-spoke. The designer will make changes to one working copy only.
Those familiar with version control may use their own wc.
>
> Andrew> and I plan to automate/script commits and updates for
> Andrew> them. However, I wonder about the best way to handle adds
> Andrew> and deletes. I've considered parsing the output of status
> Andrew> and then issuing any needed commands. However I assume
> Andrew> there is a better way. Any suggestions?
>
> http://subversion.tigris.org/faq.html#working copy-change-detection
I see. The problem would be that copied files would loose their history,
correct? Still it might be reasonable to have the designer just modify,
add or delete files, (which is the bulk of what they do). Moves would
have to be done by someone in the know. Not ideal, but I guess there are
trade-offs when shooting for transparency. Sounds like autoversioning
with WebDAV is not yet without it's quirks either.
Thanks,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automating svn add, delete
Posted by Eric Hanchrow <of...@blarg.net>.
>>>>> "Andrew" == Andrew Brosnan <an...@broscom.com> writes:
Andrew> Hello, I'm setting up a project that will have some fairly
Andrew> non-technical folks accessing some files under version
Andrew> control. (For example designers and HTML files.) Changes
Andrew> will be made on one working copy only
I would gently urge you to reconsider that -- that scheme loses many
of the benefits of version control.
Andrew> and I plan to automate/script commits and updates for
Andrew> them. However, I wonder about the best way to handle adds
Andrew> and deletes. I've considered parsing the output of status
Andrew> and then issuing any needed commands. However I assume
Andrew> there is a better way. Any suggestions?
http://subversion.tigris.org/faq.html#working copy-change-detection
--
I shrivel inside each time [Star Wars] is mentioned.
-- Sir Alec Guinness
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Automating svn add, delete
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jul 20, 2006, at 20:19, Andrew Brosnan wrote:
> I'm setting up a project that will have some fairly non-technical
> folks
> accessing some files under version control. (For example designers and
> HTML files.) Changes will be made on one working copy only, and I plan
> to automate/script commits and updates for them. However, I wonder
> about
> the best way to handle adds and deletes. I've considered parsing the
> output of status and then issuing any needed commands. However I
> assume
> there is a better way. Any suggestions?
Not necessarily, because Subversion wasn't designed to be used like
that.
Why do you want to use Subversion then, if you're not going to be
making use of so many of its core advantages?
You could consider having your designers connect to a WebDAV share of
the repository. Perhaps that would satisfy your requirements.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org