Forcing a commit

[Jason Dunham <jd...@sfis.com>]

I've searched the archives on this, and it seems apparrent that 
Subversion has no analog for the CVS -f option to force a commit.

Our development team would like to force commits for built binaries.  We 
store the binaries in the subversion repository because it's a great way 
to archive our builds and distribute them to coworkers and testers.  
Maybe that's outside the scope of Subversion, but it works really well 
for our team.  However, it's irritating to have to update the folders 
which store the installer images.  These folders are not sotred in the 
trunk, but in a separate tree for builds, parallel to the trunk.

The developers never care if there is a conflict, and on a slow net 
connection it is frustrating to have to perform a big worthless update 
right before a big commit.

Even better than a -f option on commit would be a svn:ignoreconflict 
property.

Jason Dunham
ShotSpotter, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing a commit

[Jason Dunham <jd...@sfis.com>]

Erik Huelsmann wrote:

>
>You could use svnput: it's a utility that 'puts' a file into the repository,
>overwriting what's already there. You don't even need a working copy.
>
>It's in the subversion repository in the tools/ or contrib/ dir.
>
>
>bye,
>
>
>Erik.
>
>  
>
Svnput is probably good enough, but I will still write to the dev@ list 
with the feature suggestion.  
Thanks for the info.

Jason


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing a commit

[Erik Huelsmann <e....@gmx.net>]

> --- Ursprüngliche Nachricht ---
> Von: kfogel@collab.net
> An: Jason Dunham <jd...@sfis.com>
> Kopie: users@subversion.tigris.org, rcalhoun@shotspotter.com,
> drochberg@shotspotter.com
> Betreff: Re: Forcing a commit
> Datum: 23 Jun 2005 13:34:34 -0500
> 
> Jason Dunham <jd...@sfis.com> writes:
> > There are two of us developing on the same source code in the trunk.
> > If my coworker commited the last installer image, and then I make a
> > new build, then I have to update to get his stale installer build
> > before I can commit the current one.
> 
> Thanks, now I understand.
> 
> > I like the property idea.  99% of our files work great with
> > Subversion's exsisting functionality, including everything in the
> > trunk (the source).
> > But we have a whole "build" branch with about a dozen installer
> > images, and I'd like to run a commit on the whole folder and have
> > newer files overwrite whatever is currently in the repo.  So I would
> > set a property on the whole build folder so that I could force the
> > commit on any newer file.  Of course if my coworker changed one of the
> > other images, my older copy should remain uncommitted.  If that's hard
> > to enforce, it would be fine to just run the commit on the specific
> > subfolder with a --ignore-conflicts flag.
> 
> Gosh.  I'm just not sure whether the other devs would go for this, and
> I'm not sure how I feel myself.
> 
> Would you like to post an enhancement proposal to
> dev@subversion.tigris.org and see what kind of reaction you get?  Use
> all the mails that have happened in this thread already, according to
> your judgement, and discard anything that seemed like a dead end.

You could use svnput: it's a utility that 'puts' a file into the repository,
overwriting what's already there. You don't even need a working copy.

It's in the subversion repository in the tools/ or contrib/ dir.


bye,


Erik.

-- 
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing a commit

[kf...@collab.net]

Jason Dunham <jd...@sfis.com> writes:
> There are two of us developing on the same source code in the trunk.
> If my coworker commited the last installer image, and then I make a
> new build, then I have to update to get his stale installer build
> before I can commit the current one.

Thanks, now I understand.

> I like the property idea.  99% of our files work great with
> Subversion's exsisting functionality, including everything in the
> trunk (the source).
> But we have a whole "build" branch with about a dozen installer
> images, and I'd like to run a commit on the whole folder and have
> newer files overwrite whatever is currently in the repo.  So I would
> set a property on the whole build folder so that I could force the
> commit on any newer file.  Of course if my coworker changed one of the
> other images, my older copy should remain uncommitted.  If that's hard
> to enforce, it would be fine to just run the commit on the specific
> subfolder with a --ignore-conflicts flag.

Gosh.  I'm just not sure whether the other devs would go for this, and
I'm not sure how I feel myself.

Would you like to post an enhancement proposal to
dev@subversion.tigris.org and see what kind of reaction you get?  Use
all the mails that have happened in this thread already, according to
your judgement, and discard anything that seemed like a dead end.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing a commit

[Jason Dunham <jd...@sfis.com>]

kfogel@collab.net wrote:

>Jason Dunham <jd...@sfis.com> writes:
>  
>
>>I've searched the archives on this, and it seems apparrent that
>>Subversion has no analog for the CVS -f option to force a commit.
>>
>>Our development team would like to force commits for built binaries.
>>We store the binaries in the subversion repository because it's a
>>great way to archive our builds and distribute them to coworkers and
>>testers.  Maybe that's outside the scope of Subversion, but it works
>>really well for our team.  However, it's irritating to have to update
>>the folders which store the installer images.  These folders are not
>>sotred in the trunk, but in a separate tree for builds, parallel to
>>the trunk.
>>    
>>
>
>Why are you having to update the folders?
>
>  
>
There are two of us developing on the same source code in the trunk.  If 
my coworker commited the last installer image, and then I make a new 
build, then I have to update to get his stale installer build before I 
can commit the current one.

>>The developers never care if there is a conflict, and on a slow net
>>connection it is frustrating to have to perform a big worthless update
>>right before a big commit.
>>
>>Even better than a -f option on commit would be a svn:ignoreconflict
>>property.
>>    
>>
>
>I think we'd want a --ignore-conflicts option, and/or an
>"svn:resolution" property that says how to resolve a conflict (values
>could be 'working', 'new', 'old', etc).  Thoughts?
>
>If I understood why you have to do that update, that'd help a lot,
>though.
>
>  
>
I like the property idea.  99% of our files work great with Subversion's 
exsisting functionality, including everything in the trunk (the source).
But we have a whole "build" branch with about a dozen installer images, 
and I'd like to run a commit on the whole folder and have newer files 
overwrite whatever is currently in the repo.  So I would set a property 
on the whole build folder so that I could force the commit on any newer 
file.  Of course if my coworker changed one of the other images, my 
older copy should remain uncommitted.  If that's hard to enforce, it 
would be fine to just run the commit on the specific subfolder with a 
--ignore-conflicts flag.

Thanks,
Jason

>-Karl
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing a commit

[Jason Dunham <jd...@sfis.com>]

Mark Phippard wrote:

>kfogel@newton.ch.collab.net wrote on 06/22/2005 07:39:41 PM:
>
>  
>
>>Why are you having to update the folders?
>>    
>>
>
>I would assume it is because the WC is out of date (like when another 
>developer committed the last build).  These are probably updates to 
>existing files.  One option would be to come up with a system where they 
>only commit new files.  That would solve both problems.
>
>  
>
Exactly, another developer committed the last build.


>>I think we'd want a --ignore-conflicts option, and/or an
>>"svn:resolution" property that says how to resolve a conflict (values
>>could be 'working', 'new', 'old', etc).  Thoughts?
>>    
>>
>
>I thought I read recommendations in the past that said you could provide a 
>script for diff2/diff3 or something like that, which just says there are 
>no conflicts?  He would still have to update though.
>
>Jason, did you know Subversion only stores the binary differences?  For 
>some types of binaries, even if the binary itself is large, this could be 
>a small amount of data.  Both to send over the wire and store in the 
>repository.  For other types of files, it winds up being the entire file.
>
>Mark
>
>
>
>  
>

Yes, we love the binary differences feature.  A lot of our code is in 
LabVIEW, where the source is a few hundred binary files.  Subversion has 
been the best tool we've found for keeping the code controlled, even as 
we work in different cities and do a fair amount of travelling too.  
Source code updates are generally very fast.  But when we create an 
installer, the all the source code and the runtime engine are thrown 
into some MSI file, and because of the compressed format, the binary 
diffing doesn't help at all.

It's not the end of the world to update before we commit, but it is 
getting more annoying. 

Thanks,
Jason


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing a commit

[Mark Phippard <Ma...@softlanding.com>]

kfogel@newton.ch.collab.net wrote on 06/22/2005 07:39:41 PM:

> Why are you having to update the folders?

I would assume it is because the WC is out of date (like when another 
developer committed the last build).  These are probably updates to 
existing files.  One option would be to come up with a system where they 
only commit new files.  That would solve both problems.

> I think we'd want a --ignore-conflicts option, and/or an
> "svn:resolution" property that says how to resolve a conflict (values
> could be 'working', 'new', 'old', etc).  Thoughts?

I thought I read recommendations in the past that said you could provide a 
script for diff2/diff3 or something like that, which just says there are 
no conflicts?  He would still have to update though.

Jason, did you know Subversion only stores the binary differences?  For 
some types of binaries, even if the binary itself is large, this could be 
a small amount of data.  Both to send over the wire and store in the 
repository.  For other types of files, it winds up being the entire file.

Mark




_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Forcing a commit

[kf...@collab.net]

Jason Dunham <jd...@sfis.com> writes:
> I've searched the archives on this, and it seems apparrent that
> Subversion has no analog for the CVS -f option to force a commit.
> 
> Our development team would like to force commits for built binaries.
> We store the binaries in the subversion repository because it's a
> great way to archive our builds and distribute them to coworkers and
> testers.  Maybe that's outside the scope of Subversion, but it works
> really well for our team.  However, it's irritating to have to update
> the folders which store the installer images.  These folders are not
> sotred in the trunk, but in a separate tree for builds, parallel to
> the trunk.

Why are you having to update the folders?

> The developers never care if there is a conflict, and on a slow net
> connection it is frustrating to have to perform a big worthless update
> right before a big commit.
> 
> Even better than a -f option on commit would be a svn:ignoreconflict
> property.

I think we'd want a --ignore-conflicts option, and/or an
"svn:resolution" property that says how to resolve a conflict (values
could be 'working', 'new', 'old', etc).  Thoughts?

If I understood why you have to do that update, that'd help a lot,
though.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org